--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
mostawesomed...@gmail.com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
mostawesomed...@gmail.com
Corbin Simpson
mostawesomed...@gmail.com
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance
beyond their reach. ~ Unknown
Corbin Simpson
mostawesomed...@gmail.com
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications
On Fri, Mar 5, 2010 at 11:38 AM, Corbin Simpson
mostawesomed...@gmail.com wrote:
I was trying my hardest to not say anything, but...
[blah blah Fedora blah Ubuntu blah staging blah blah]
That said... Code probably is moving too fast inside nouveau. There is
a bit of a wall to go through
.
Posting from a mobile, pardon my terseness. ~ C.
On Mar 5, 2010 1:51 PM, ty...@mit.edu wrote:
On Fri, Mar 05, 2010 at 11:38:46AM -0800, Corbin Simpson wrote:
If distros want to run weird exper...
So what distro would you recommend for people who want to do kernel
development, do kernel testing
0xFFFC);
--
1.6.4.4
Seems entirely reasonable. Haven't tested, though.
Reviewed-by: Corbin Simpson mostawesomed...@gmail.com
--
Only fools are easily impressed by what is only
barely beyond their reach. ~ Unknown
Corbin Simpson
mostawesomed...@gmail.com
From fe9c18cb5f4417558d40be7372c8bb74b613d470 Mon Sep 17 00:00:00 2001
From: Corbin Simpson mostawesomed...@gmail.com
Date: Wed, 10 Feb 2010 10:56:56 -0800
Subject: [PATCH] glean: Disable dithering for clipFlat.
Allows r300g to handily pass.
---
tests/glean/tclipflat.cpp |2 ++
1 files
From 215714d54a7f38b9add236bcc1c795e8b5d92867 Mon Sep 17 00:00:00 2001
From: Corbin Simpson mostawesomed...@gmail.com
Date: Wed, 10 Feb 2010 10:39:18 -0800
Subject: [PATCH] mesa/st: Gallium quads, by spec, never change provoking vertex.
Fixes glean/clipFlat. Softpipe might be broken; I haven't
Can we piggyback the mspos changes on the bump? I have discovered a legit
non-AA use for them so I would like them to be usable.
Posting from a mobile, pardon my terseness. ~ C.
On Feb 4, 2010 8:07 AM, Alex Deucher alexdeuc...@gmail.com wrote:
From 8ea32b7974dbcf819545f555ca078f709da5ff4e Mon
Heh, this has stuff from a couple of private patches I never submitted.
Reviewed-by: Corbin Simpson mostawesomed...@gmail.com
On Thu, Feb 4, 2010 at 11:03 PM, Alex Deucher alexdeuc...@gmail.com wrote:
From 979e9e6ecb586e92b2354a5fe8d73f3d7bfa85b3 Mon Sep 17 00:00:00 2001
From: Alex Deucher
://p.sf.net/sfu/rsaconf-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
--
Only fools are easily impressed by what is only
barely beyond their reach. ~ Unknown
Corbin
Two patches attached, one for the kernel and one for the DDX.
Comments welcome; I have no idea exactly how to handle the case where
the DDX is newer than the kernel. Do we need to make a patchlevel
version bump and check?
~ C.
--
Corbin Simpson
mostawesomed...@gmail.com
0001-drivers-gpu-drm
-0800, Corbin Simpson wrote:
Two patches attached, one for the kernel and one for the DDX.
Comments welcome; I have no idea exactly how to handle the case where
the DDX is newer than the kernel. Do we need to make a patchlevel
version bump and check?
If ddx is newer than the kernel than we
I will pop my rv410 back in and test when I get back home.
Posting from a mobile, pardon my terseness. ~ C.
On Jan 6, 2010 2:41 AM, Jerome Glisse jgli...@redhat.com wrote:
From: Corbin Simpson mostawesomed...@gmail.com
Long story short, this fixes sporadic hardlocks with my rv410 during
times
From 7c1de3201bd4e965da7c1d542c46d8b2725bf42d Mon Sep 17 00:00:00 2001
From: Corbin Simpson mostawesomed...@gmail.com
Date: Fri, 18 Dec 2009 01:00:57 -0800
Subject: [PATCH] drivers/radeon/kms: Workaround RV410/R420 CP errata.
Long story short, this fixes sporadic hardlocks with my rv410 during
Currently making music; expect a Tested-By in a couple hours.
Posting from a mobile, pardon my terseness. ~ C.
On Dec 6, 2009 7:22 PM, Dave Airlie airl...@gmail.com wrote:
From: Dave Airlie airl...@redhat.com
This adds support for compressed textures to the r100-r500 CS
checker, it lets me run
I will be around via the more traditional IRC. Maybe a freenode channel
would be a good way for absentees to stay in touch.
Posting from a mobile, pardon my terseness. ~ C.
On Nov 12, 2009 4:54 PM, Jens Owen j...@stormpeakinnovations.com wrote:
Well...it will be a miracle if we can stream it
On 10/21/2009 03:49 PM, Jerome Glisse wrote:
Hi,
I think we should merge the read write domain of radeon KMS
into a single domains information. I don't think there is a
good reason for separate read write domain, we did copy intel
model for that and intel use this mostly for cache
On 09/22/2009 01:19 PM, Nicolai Hähnle wrote:
I'm pretty confident that you can write a perfectly legal OpenGL application
that creates commands that take *minutes* to run on decent graphics cards.
Just produce a huge number of screen-sized primitives and use a very long
fragment program
On 09/01/2009 02:06 PM, Daniel Vetter wrote:
On Tue, Sep 01, 2009 at 10:56:18AM -0400, Alex Deucher wrote:
I'm failing to see why we need an overlay ioctl at all. You end up
pulling a relatively large amount of state setup into the drm. Why
not treat the overlay like EXA or textured video or
Keith Packard wrote:
Paul McKenney reminds me that submissions for the X track at Plumbers
are due shortly (Monday, 15 June 2009 PDT); I'd love to hear from anyone
interested in helping with a presentation or other content for our slot.
I'm interested in hearing about presentations,
Enno Fennema wrote:
My longer term aim is to understand what my Radeon SE9200 can and cannot
do. Mesa is so clever that it hides by software when hardware is
deficient. I think that only by getting access to the the drm kernel
driver can I start exploring the hardware.
The DRM only exposes a
Right now, in order to create a driver, you need to combine three pieces.
The pipe is the core of acceleration for a given chipset. It contains
all of the code necessary to accelerate things, and exposes two generic
structs in the Gallium API: pipe_screen, which is information about the
current
demetrioussha...@netscape.net wrote:
So that means that I can get hardware acceleration by writing the winsys for
Syllable, regardless of the fact that we don't use DRI/DRM?? I guess the main
question is, Do I have to use the DRI/DRM drivers in order to use the
current hardware pipes?
And
demetrioussha...@netscape.net wrote:
Sounds good, but here's the catch, I would like to use Gallium to accelerate
the whole windowing system.? I want our windowing system to use libGL for all
rendering, so Gallium would basically be running on the video card with no
windowing system
Richard Purdie wrote:
On Thu, 2009-03-19 at 12:03 -0400, Sindhudweep Sarkar wrote:
This might be the opinion of a completely non educated end user but it
seems that an intel specific drm and other bits (xorg, mesa) would be
somewhat of a maintenance waste.
TI-OMAP 3xxx and a couple of other
not to care about warnings. That will
get fixed.
Indeed. I have been running 64 bit builds for quite a while now, and
merely ignored the warnings as not my problem. In the future, I shall
make it my problem.
~ C.
- --
~ Corbin Simpson
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG
be *really* nice if AMD happened to know the magic numbers for
getting the HW fog to behave exactly like OpenGL fog. *wink, wink*
~ C.
- --
~ Corbin Simpson
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
is lackluster at best. I've tried a few different
times to improve it, but it defies simple solutions. Maybe I'll try
again in a bit.
~ C.
- --
~ Corbin Simpson
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http
without an NDA.
Fortunately, the r200 DRI driver in Mesa is pretty much self-documented.
~ C.
- --
~ Corbin Simpson
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Roland Scheidegger wrote:
On 20.07.2008 19:32, Corbin Simpson wrote:
Howdy. I was just going through the r3xx/r5xx bugs, and I noticed that
lots of problems are related to certain texture compression features
being dependent on out-of-tree code. I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp Klaus Krause wrote:
Stefan Dösinger schrieb:
This may be slightly off topic, but I am wondering if there's any way to
detect the ability to upload precompressed textures when
GL_EXT_texture_compression_s3tc is not available(aka the user
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Howdy. I was just going through the r3xx/r5xx bugs, and I noticed that
lots of problems are related to certain texture compression features
being dependent on out-of-tree code. I also noticed that, at least on
R400+ Radeons, we actually have hardware
34 matches
Mail list logo
