rashed.
Please try the 3DKnots screensaver.
Regards
Oliver
--
--
___
Dri-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dri-devel
On Tue, 2010-01-19 at 20:18 +0100, Vignatti Tiago (Nokia-D/Helsinki)
wrote:
> Some drivers use DRI2 protocol but implement their own kernel rendering
> mananger. For these drivers, libdrm becomes useless.
>
> The only inconvenient right now to put libdrm optional to X server is
> concerning DRI2Au
ROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Thanks,
Oliver
-
This SF.Net email is sponsored by the Moblin Your Move Developer's
Done. Took a little longer because I had to clone a clean tree so I could push
the patch... I have a lot of changes in my local Mesa that are not quite ready
to be pushed yet.
On 6/21/07, Oliver McFadden <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I accidentally used |= instead of =. I&
Hi,
I accidentally used |= instead of =. I'll push the fix now.
Thanks for reporting the bug. :)
On 6/21/07, Panagiotis Papadakos <[EMAIL PROTECTED]> wrote:
> Hi everybody.
>
> I think that
> http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=commit;h=da1d9d97959bd1e4c8e359d28b4fd6cafdd4168a
> b
This looks like DTX or S3TC texture compression (which is partially broken); I
think there should be some more information on this on the list, and how to
disable it.
On 6/12/07, Mikko Rauhala <[EMAIL PROTECTED]> wrote:
> ti, 2007-06-12 kello 02:26 +0000, Oliver McFadden kirjoit
Hi,
I couldn't reproduce this with the latest Git of Mesa and DRM. Although R300
does have some lockup problems that get triggered after running UT2004 for a
while...
Try again using the latest Mesa and DRM from Git, and let me know if the texture
corruption problem still exists.
Thank you.
On
I think this register is the same on mobility and standard chips.
I still haven't figured it out yet, although airlied gave me a few pointers
about it.
I think that unless we can find some way to make the blob change it, it might
not be possible to determine what it does...
On 5/28/07, Martijn
Hi,
I was talking to airlied on #dri-devel about figuring out the R300_VAP_CNTL
(0x2080) register. He explained that it controls the vertex shader engine, but
other than that we don't really know. This register could be card dependent, so
I modified radeontool to dump it, and I'm posting here aski
My thoughts are, we should unify the really common stuff... but I don't think
it's possible to unify r200_tex.c and r300_tex.c. The hardware is different, and
the file would end up with an #ifdef on every 3rd line; it doesn't make sense
here.
Just for really common code it does.
I don't know what
Hi,
I have a few questions about the R300 driver. I'm just wondering about a couple
of things including the OPTIMIZE_ELTS code (r300_render.c) and
R300_VAP_INPUT_ROUTE_0_0 and R300_VAP_INPUT_ROUTE_1_0.
I cleaned up the OPTIMIZE_ELTS code to reduce duplication, and I verified that
both the optimiz
Talk is cheap. Show me the code.
Or in our case, specs... I'll get excited then. Until they do that this is just
ATI making wild claims.
On 5/11/07, Jacek Poplawski <[EMAIL PROTECTED]> wrote:
> http://www.0xdeadbeef.com/weblog/?p=288
>
> Probably nobody knows what does it mean, but maybe it's a
Done.
On 5/9/07, Brian Paul <[EMAIL PROTECTED]> wrote:
> If it's just dead code removal, go ahead.
>
> -Brian
>
> Oliver McFadden wrote:
> > Well both Keith and Jerome are okay with me removing the VTXFMT code, so
> > I'll go
> > ahead and do that
/07, Brian Paul <[EMAIL PROTECTED]> wrote:
> Oliver McFadden wrote:
> > I also think we might need to add _dri_warning/_dri_error because the
> _mesa
> > versions output "Mesa warning: %s" which implies to the user this is a
> Mesa
> > problem, not a DRI dri
Here is the patch.
On 5/9/07, Oliver McFadden <[EMAIL PROTECTED]> wrote:
I'd like some input on the VBO stuff in r300. In r300_context.h we have the
following.
/* KW: Disable this code. Driver should hook into vbo module
* directly, see i965 driver for example.
*/
ade a patch for this, but I'm not committing until I get the okay
from a few people.
Thanks.
On 5/9/07, Oliver McFadden <[EMAIL PROTECTED]> wrote:
> I also think we might need to add _dri_warning/_dri_error because the _mesa
> versions output "Mesa warning: %s" which im
ions... So maybe adding them to the common DRI code?
On 5/9/07, Oliver McFadden <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I added the "not implemented yet" comment back, although there are other
> places
> that use 65535 so it could be some kind of hardware limit...
>
&g
Hi,
I added the "not implemented yet" comment back, although there are other places
that use 65535 so it could be some kind of hardware limit...
The only reason that I went with "camel case" r300FooBar names is because that's
what 90% of the driver uses; it's easier to change a few r300_foo_bar t
On 5/4/07, Jerome Glisse <[EMAIL PROTECTED]> wrote:
> There was a typo in my mail, i meaned lock not lockup
> when i was talking about apps sending data to gpu.
> And if multiple instance of glxgears are successfull
> to make the gpulockup this is because you are then
> sending megs of vertex to th
On 5/3/07, Zoltan Boszormenyi <[EMAIL PROTECTED]> wrote:
> Hi,
>
> sorry for the crossposting, I don't know who to address.
>
> I am experimenting the new CFS scheduler on Linux
> and tried to start multiple glxgears to see whether
> they are really running smooth and have evenly
> distributed fram
I just updated the tool to (hopefully) calculate the AGP aperture address and
size dynamically. I'm using some code borrowed from REnouveau.
I haven't tested this yet, but it should work.
Again, if anyone is using this I'd like to get feedback on what features would
be useful. Currently I plan to
On 4/26/07, Phillip Ezolt <[EMAIL PROTECTED]> wrote:
> Oliver & Dave,
>
> >
> > You maybe have missed out on #dri-devel on freenode irc, it works
> > reasonably well for getting insta-answers depending on timezone etc..
>
> Ah. I HAVE missed that. I&#x
On 4/23/07, Dave Airlie <[EMAIL PROTECTED]> wrote:
>
> >
> >> I just started reading the X code about 6 months ago, and the learning
> >> curve has been steep. My emails to dri-devel are answered now and
> >> again, and that is kinda frustrating when you want an answer NOW.
>
> You maybe have miss
On 4/23/07, Phillip Ezolt <[EMAIL PROTECTED]> wrote:
> Awesome.
>
> As an aside, I would really like to make it easier for other people to
> hack on radeon & X.
> I've been fighting with my Radeon 200M for months, hacking when I have
> spare time.
I think we have similar goals here. I'm doing this
On 4/23/07, Phillip Ezolt <[EMAIL PROTECTED]> wrote:
> Oliver,
> I've been hacking on the RS480 (Radeon 200M) for a while, and Dave
> has (aweseomely) brought it to a point where it has the working GART,
> and a limping Mesa.
>
> Currently triangles are broken, and I
I've previously filed a bug report (bug #10211) about the
R300_RB3D_DSTCACHE_CTLSTAT issue, however I couldn't prove the proposed patch
was correct. I've investigated this further and I can confirm that the blob
indeed writes 0xa to R300_RB3D_DSTCACHE_CTLSTAT before 3D operations, and 0x2
after 3D
On 3/18/07, Brian Paul <[EMAIL PROTECTED]> wrote:
> All the Glean tests that check for specific rendering results already
> have an error margin.
>
> Can you be more specific about which tests are failing and how the error
> margin might need to be changed?
>
> -Brian
I previously replied (but for
On 3/18/07, Nicolai Haehnle <[EMAIL PROTECTED]> wrote:
> I just realized I didn't send it to the list:
>
> There was yet another problem with reordering of instructions. The
> attached patch (which is against my earlier patch) should fix this.
I can confirm this fixes my problems with the first pa
Another thought; the same changed are probably needed for the vertprog code. I
think there are also a lot of bugs there.
On 3/18/07, Oliver McFadden <[EMAIL PROTECTED]> wrote:
> This patch seems to break one of my longer fragment programs. I believe this
> is
> because it&#
This patch seems to break one of my longer fragment programs. I believe this is
because it's running out of registers, but I haven't looked into it in detail
yet.
I think this patch should be committed, but directly followed by a patch to
reduce the number of registers used.
On 3/18/07, Nicolai
I notice some failures with the example tests (R300) that seem to just be
slight precision errors; I think you should add a margin for error because
usually the hardware will implement things in a faster, perhaps less precise
way.
This lower precision is still "good enough", though.
On 3/17/07,
This is very interesting and useful. Seems it's already showing some areas where
improvement is required in the R300 driver.
I'd suggest getting an account on freedesktop.org and a Git repository there. :)
Sourceforge is... less than reliable.
-
Quoting Jon Smirl ([EMAIL PROTECTED]):
> --- Denis Oliver Kropp <[EMAIL PROTECTED]> wrote:
> > I don't know how that's handled by others,
> > but DirectFBGL applications have to Lock() and
> > Unlock() the context.
> > Only one context can be locked at
om the context?
You should have a look at how it's done for MGA in the embedded-2-branch.
The DRM module provides an "extended state" bound to each context
without breaking compatibility.
--
Bes
Quoting Michel Dänzer ([EMAIL PROTECTED]):
> On Wed, 2003-08-06 at 21:43, Denis Oliver Kropp wrote:
> >
> > When DRI has the graphics card lock for more than 100 ms, DirectFB
> > uses software rendering even if hardware rendering was available.
>
> I'm cur
Quoting Brian Paul ([EMAIL PROTECTED]):
> Denis Oliver Kropp wrote:
> >Quoting Brian Paul ([EMAIL PROTECTED]):
> >
> >>Denis Oliver Kropp wrote:
> >>
> >>>Quoting Keith Whitwell ([EMAIL PROTECTED]):
> >>>
> >>>
> >
tX into GL
> right now, but I could well imagine that they'd like to use DRI directly
> (or rather, indirectly through an DirectX-like API based on DRI).
DirectFB is DirectX-like, WineX could use DRI via DirectFBGL.
--
Best regards,
Denis Oliver Kropp
.---
Quoting Denis Oliver Kropp ([EMAIL PROTECTED]):
> dri/common/ contains reusable code used by the DRI drivers
> while dri/common/api/ contains code to handle the drivers.
dri/api/, of course.
--
Best regards,
Denis Oliver Kropp
.--.
| Di
Quoting Brian Paul ([EMAIL PROTECTED]):
> Denis Oliver Kropp wrote:
> >Quoting Keith Whitwell ([EMAIL PROTECTED]):
> >
> >>Brian Paul wrote:
> >>
> >>>> dri/- dri driver interface
> >>>> api/-
Quoting Brian Paul ([EMAIL PROTECTED]):
> Denis Oliver Kropp wrote:
>
> >>Also, I want to try to keep all source files as leaves in the tree.
> >>That is, a directory foo/ won't contain both files and subdirs; just
> >>one or the other.
> >
> >
&
mebuffer device wouldn't need that much code to
add hardware accelerated OpenGL support.
--
Best regards,
Denis Oliver Kropp
.--.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
"---
Quoting Brian Paul ([EMAIL PROTECTED]):
> Denis Oliver Kropp wrote:
> >I think the DRI drivers should be moved into the dri/ directory
> >which itself should be in the drivers/ directory, because drivers/
> >contains the public APIs of Mesa, e.g. OSMesa, fxMesa etc.
>
dule. Where would that live?
There will be no DirectFB Mesa driver module. The DirectFB specific part
resides in the loadable module of IDirectFBGL. This module will use the
DRI driver interface from drivers/dri/, i.e. DRIMesaCreateContext etc.
--
Best regards,
Denis Oliver Kropp
.
dri/- dri driver interface
common/ - reusable driver code
radeon/ - DRI/fbdev driver
r200/ - DRI/fbdev driver
mga/
hich is the new development branch needs updates
to miniglx.c and the radeon driver to work with the recent changes for
window system independence. When do you need it?
I agree with Keith's comments on the driver directory structure.
--
Best regards,
Quoting Linus Torvalds ([EMAIL PROTECTED]):
>
> On Fri, 30 May 2003, Denis Oliver Kropp wrote:
> >
> > In the kernel part of Fusion (our IPC API) I'm currently calling yield()
> > after unlocking a "long-time" lock. Maybe you have some hints before I'
atch, because SysV IPC was
not sufficient enough to reach the current level of stability and speed.
--
Best regards,
Denis Oliver Kropp
.--.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/
1mat3mny8an4a4zd1kqnq
Stop
Mailings Here
xkauuq3vpvv9zlhu3hiy
sembly hacking skillz. :)
DirectFB has optimized memcpy routines using MMX or SSE "mov" with non-temporal
storage if supported.
I've attached the pretty standalone files.
--
Best regards,
Denis Oliver K
Quoting Jens Owen ([EMAIL PROTECTED]):
> Denis Oliver Kropp wrote:
> >Quoting Ian Romanick ([EMAIL PROTECTED]):
> >
> >>Denis Oliver Kropp wrote:
> >>
> >>>Hi,
> >>>
> >>>I just branched the embedded-1-b
a connect3d
Radeon 9000 128mb
linux totally fully and completly locks when selecting transparant blocks.
The meaning of this post, just a simple bug report.
Sure it could be a leocad bug, but since the r200 drivers are highly in
development i figured this is the place that
On Saturday 06 July 2002 21:49, Jens Owen wrote:
> Oliver Feiler wrote:
> > On Saturday 06 July 2002 17:36, Oliver Feiler wrote:
> >>On Friday 05 July 2002 13:04, José Fonseca wrote:
> >>>Keith Whitwell confirmed the readiness of the r200-0-1-branch for
> &g
On Saturday 06 July 2002 23:11, Keith Whitwell wrote:
> Jens Owen wrote:
> > Oliver Feiler wrote:
> >> On Saturday 06 July 2002 17:36, Oliver Feiler wrote:
> >>> On Friday 05 July 2002 13:04, José Fonseca wrote:
> >>>> Keith Whitwell confi
On Saturday 06 July 2002 17:36, Oliver Feiler wrote:
> On Friday 05 July 2002 13:04, José Fonseca wrote:
> > Keith Whitwell confirmed the readiness of the r200-0-1-branch for
> > testing and for binary snapshots.
>
> Just tested this driver on a system with original ATI 85
ng the first few lines so there is nothing
useful there as well. That's all informtation I can give unfortunately.
Summary: it crashes. ;)
--
Oliver Feiler
http://www.lionking.org/~kiza/ <-- homepage
PGP-key ID 0x561D4FD2--> /pgpkey.shtml
-
Small update:
Using the old kernel module
[drm] Initialized radeon 1.2.0 20010405 on minor 0
does not produce the problem. The TcL code gets deactivated though.
Bye
On Thursday 30 May 2002 19:34, Oliver Feiler wrote:
> Hi,
>
> I tried the tcl-0-0-branch from DRI cvs (downloaded
deon 20020309 AGP 4x x86/MMX/3DNow! TCL
OpenGL version string: 1.2 Mesa 4.0.1
-Oliver
--
Oliver Feiler
http://www.lionking.org/~kiza/ <-- homepage
PGP-key ID 0x561D4FD2--> /pgpkey.shtml
___
Don't miss the 2002 Spr
Hi,
I get the same thing in tuxracer - penguin is only occasionally drawn, but then it
looks fine.
For UT, I cannot run it - I just get a black screen (or window, when I changed config
to be not full-screen). Can someone email me their .ini file so I can try that?
This is with mach64-0-0-3
58 matches
Mail list logo
