Am Samstag, 9. Oktober 2004 03:33 schrieb Ian Romanick:
Ian Romanick wrote:
Here's a simple patch that gives about a 50% (on my box) speed boost to
glReadPixels performance in 24-bit. I measured using the benchmark
built into progs/demos/readpix. The interesting thing is that the core
So from my point of view it should be safe for the via drm to go into the
kernel.
Okay I'll try and sort out a patch ASAP, just came back from some deep sea
fishing, need to go to bed now :-)
Dave.
The Mesa driver might need to correct for version number bumps.
/Thomas
Hi!
Just tried out the core-based drm today, and I notice that
drmOpen(via) does not work anymore.
What is the correct way to fix up this? I suspect my client should be using
drmOpenByBusID ?
Regards
Thomas
---
This SF.net email is sponsored
Is this a left over from gamma maybe?
correct,
I've killed them in CVS, and I'll push a patch to Linus tree also..
Dave.
leading to the null dereference.
I assume these lines need to be wrapped in an
if(drm_core_check_feature(dev, DRIVER_HAVE_DMA)) { } or something, but
I'll
Just tried out the core-based drm today, and I notice that
drmOpen(via) does not work anymore.
I think this should still work, as we are meant to retain backwards compat
for older clients.. drmOpen calls drmOpenByBusID anyways in libdrm..
there may be something else wrong..
Dave.
What is
On Fri, 08 Oct 2004 14:09:49 -0700, Eric Anholt [EMAIL PROTECTED] wrote:
On Fri, 2004-10-08 at 13:40, Marcello Maggioni wrote:
On Fri, 08 Oct 2004 13:23:03 -0700, Eric Anholt [EMAIL PROTECTED] wrote:
On Fri, 2004-10-08 at 08:41, Dieter Nützel wrote:
Am Freitag, 8. Oktober 2004 17:37
On Sat, 9 Oct 2004 14:08:58 +0200, Marcello Maggioni [EMAIL PROTECTED] wrote:
On Fri, 08 Oct 2004 14:09:49 -0700, Eric Anholt [EMAIL PROTECTED] wrote:
On Fri, 2004-10-08 at 13:40, Marcello Maggioni wrote:
On Fri, 08 Oct 2004 13:23:03 -0700, Eric Anholt [EMAIL PROTECTED] wrote:
On
On Friday 08 October 2004 17:22, David wrote:
Hi. Common and savage snapshots from 20041008 are giving me this at the
XFree86 startup:
You cannot use modules compiled for Xorg 6.8 on XFree86 anything.
- ajax
pgpxBCYvv8OlM.pgp
Description: PGP signature
Hi,
Okay the VIA DRM people have asked to include it in the kernel, it
only allows accelerated XvMC for non-root users, and 3d for root users
(the 3d paths are still not secure)...
The bk tree at
bk://drm.bkbits.net/drm-via
the patch against Linus latest (along with some cleanup
Hi, Dave.
Hi,
Okay the VIA DRM people have asked to include it in the kernel, it
only allows accelerated XvMC for non-root users, and 3d for root users
(the 3d paths are still not secure)...
The bk tree at
bk://drm.bkbits.net/drm-via
the patch against Linus latest (along with
On Sat, 9 Oct 2004, [ISO-8859-1] Thomas Hellström wrote:
Hi!
Just tried out the core-based drm today, and I notice that
drmOpen(via) does not work anymore.
What is the correct way to fix up this? I suspect my client should be using
drmOpenByBusID ?
This is also broken on radeon's (yesterdays
because of this patch, only r300_demo will work.
Even that would be progress, no? Currently, when I move the xterm window,
I can notice the screen flicker -- on Radeon 9600 and a 3GHz processor...
You would get slightly faster 2d rendering, but non-CP 2d should be plenty
fast for moving xterm.
On Sat, 9 Oct 2004 14:14:29 +0200
Marcello Maggioni [EMAIL PROTECTED] wrote:
[snip]
Hey , I've solved in setting by DRICONF 5 Texture units instead of 6 .
There's something wrong in using 6 Texture units with lastest DRI drivers?
Marcello
The more texture units you have the smaller
On Sat, 9 Oct 2004 09:09:52 -0400
Adam Jackson [EMAIL PROTECTED] wrote:
On Friday 08 October 2004 17:22, David wrote:
Hi. Common and savage snapshots from 20041008 are giving me this at the
XFree86 startup:
You cannot use modules compiled for Xorg 6.8 on XFree86 anything.
I thought they
Mikhail, ati.patch.3 is patch for *2D* driver to enable DRI.
However, at the moment, there is *NO* 3d driver for R300 cards except the
binary only ati one.
So yes, the DRI will be enabled. But, NO, you will not get 3d rendering
because of this patch, only r300_demo will work.
Even that
On Sat, 9 Oct 2004 18:00:47 +0200, Felix Kühling [EMAIL PROTECTED] wrote:
On Sat, 9 Oct 2004 14:14:29 +0200
Marcello Maggioni [EMAIL PROTECTED] wrote:
[snip]
Hey , I've solved in setting by DRICONF 5 Texture units instead of 6 .
There's something wrong in using 6 Texture units with
On Sat, 9 Oct 2004 10:59:35 -0400 (EDT), Vladimir Dergachev
[EMAIL PROTECTED] wrote:
On Sat, 9 Oct 2004, [ISO-8859-1] Thomas Hellström wrote:
Just tried out the core-based drm today, and I notice that
drmOpen(via) does not work anymore.
What is the correct way to fix up this? I suspect my
Hi.
Jon Smirl wrote:
On Sat, 9 Oct 2004 10:59:35 -0400 (EDT), Vladimir Dergachev
[EMAIL PROTECTED] wrote:
On Sat, 9 Oct 2004, [ISO-8859-1] Thomas Hellstrm wrote:
Just tried out the core-based drm today, and I notice that
drmOpen("via") does not work anymore.
What
It's the worst one I've ever seen.
After some seconds (during first cycle) it falsely draw a few triangles in the
_upper right_ corner.
Whole system lockup.
Even the monitor goes into 'no signal mode'.
SYSRQ didn't work.
I have to press 'the button'.
-Dieter
BTW What about the 'texcyl'
On Saturday 09 October 2004 12:02, Felix Kühling wrote:
On Sat, 9 Oct 2004 09:09:52 -0400
Adam Jackson [EMAIL PROTECTED] wrote:
On Friday 08 October 2004 17:22, David wrote:
Hi. Common and savage snapshots from 20041008 are giving me this at the
XFree86 startup:
You cannot use
On Sat, 9 Oct 2004, Jon Smirl wrote:
On Sat, 9 Oct 2004 10:59:35 -0400 (EDT), Vladimir Dergachev
[EMAIL PROTECTED] wrote:
On Sat, 9 Oct 2004, [ISO-8859-1] Thomas Hellström wrote:
Just tried out the core-based drm today, and I notice that
drmOpen(via) does not work anymore.
What is the correct way
An issue raised by DRM people with the new drm core is how to stop users
shotting themselves in the foot when upgrading drm modules from CVS and
mixing up cores and drivers...
This patch (against DRM CVS) proposes a simple internal version that gets
passed from the module to the core, when built
Marcello Maggioni wrote:
I've tried your hint of increasing the AGP size with GARTSize option.
Actually, increasing GARTSize will do nothing for the r200
driver, as it doesn't really use GART memory at all (only if you use
Mesa's glx memory allocator) afaik. The r200 driver uses only 1 texture
I fixed the programs in DRM cvs /tests to build. You can use them to
test drmOpen like this:
./drmstat -o radeon -v
It looks to me like the lower level part of drmOpen is working
correctly. You need to trace into libxf86drm and see what is failing
at a higher level. The ioctl nr=0 followed by
How strong of match requirement do we need? Note that this only
impacts distribution of binary personality modules, if you have source
there is no problem.
Several stronger solutions:
on each CVS check-in to DRM increment a count and use this for an id
manual version number for DRM
embed the
How strong of match requirement do we need? Note that this only
impacts distribution of binary personality modules, if you have source
there is no problem.
Not really I'm thinking more of someone building a module against one core
and insmodding it against another one.. so someone builds a
This only happens with UT2004 menu backgrounds (with DOOM3 I haven't
such problems)
I didn't see any problems when I last looked at it, I'll see if I can
reproduce it next week.
the patch checked in is missing the bit that incresases max texture size
when using compressed, as it is a
27 matches
Mail list logo
