the posted driver has some ttm hooks in it.
>
>
> --
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/fir
the posted driver has some ttm hooks in it.
>
>
> --
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/fir
getting prepared for merge? Lots of churn. Gallium's
all mix'n'match though, so it shouldn't be a big deal further down the
road.
Sorry for not speaking up sooner; it's finals week and my attention to
every single email in my box is rather limited. :3
~ C.
--
When t
.
Posting from a mobile, pardon my terseness. ~ C.
On Mar 5, 2010 1:51 PM, 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, and do ker
On Fri, Mar 5, 2010 at 11:38 AM, Corbin Simpson
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
exactly pleased with the
suggestion of retooling all of the r600 userspace over a change to the
CS system; we just spent the better part of a year moving everything
over to CS!)
~ C.
--
Only fools are easily impressed by what is only
barely beyond their reach. ~ Unknown
Corbin Simpson
dev->r600_blit.state_offset;
> radeon_ring_write(rdev, PACKET3(PACKET3_INDIRECT_BUFFER, 2));
> radeon_ring_write(rdev, gpu_addr & 0xFFFC);
> --
> 1.6.4.4
Seems entirely reasonable. Haven't tested, though.
Reviewed-by: Corbin Simpson
--
Only fools are easil
>From 215714d54a7f38b9add236bcc1c795e8b5d92867 Mon Sep 17 00:00:00 2001
From: Corbin Simpson
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 figured out
how to
>From fe9c18cb5f4417558d40be7372c8bb74b613d470 Mon Sep 17 00:00:00 2001
From: Corbin Simpson
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 changed, 2 insertions(+)
Not yet. Work is in progress.
Posting from a mobile, pardon my terseness. ~ C.
On Feb 6, 2010 10:27 AM, "Zoltan Boszormenyi" wrote:
Hi,
I would like to ask whether current Mesa and xf86-drv-ati
supports the new low cost, passively cooled Radeon 5450?
Thanks in advance,
Zoltán Böszörményi
--
Heh, this has stuff from a couple of private patches I never submitted.
Reviewed-by: Corbin Simpson
On Thu, Feb 4, 2010 at 11:03 PM, Alex Deucher wrote:
> >From 979e9e6ecb586e92b2354a5fe8d73f3d7bfa85b3 Mon Sep 17 00:00:00 2001
> From: Alex Deucher
> Date: Fri, 5 Feb 2010 01
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" wrote:
>From 8ea32b7974dbcf819545f555ca078f709da5ff4e Mon Sep 17 00:00:00 2001
__
> Dri-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
--
Only fools are easily impressed by what is only
barely beyond their reach. ~ Unknown
Corbin Simpson
---
> Dri-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
--
Only fools are easily impressed by what is only
barely beyond their reach. ~ Unknown
Corbin Simpson
-
the
> ddx the mspos settings (mesa stills need to check for kernel support).
>
> Cheers,
> Jerome
>
--
Only fools are easily impressed by what is only
barely beyond their reach. ~ Unknown
Corbin Simpson
0001-drivers-gpu-drm-radeon-Permit-userspace-to-write-MSA.patch
Description:
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
0001-drivers-gpu-drm-radeon-Permit-userspace-to
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" wrote:
From: Corbin Simpson
Long story short, this fixes sporadic hardlocks with my rv410 during
times of intense 2D acceleration (Fl
>From 7c1de3201bd4e965da7c1d542c46d8b2725bf42d Mon Sep 17 00:00:00 2001
From: Corbin Simpson
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
times of intense
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" wrote:
From: Dave Airlie
This adds support for compressed textures to the r100->r500 CS
checker, it lets me run openarena and the demos in mesa
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" wrote:
Well...it will be a miracle if we can stream it live; but we are going
to try.
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 vi
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, demo
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
[email protected] 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 sta
[email protected] 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?"
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 ch
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
h of test boxes that run 64-bits, unfortunately, the
> people doing builds there appear 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
mak
branch? :3
Yeah, as you guys may have noticed, fixing fog coords in one place tends
to badly break it in other places. I think the entire fog handling
system for r300 needs to be scrubbed and re-written.
Gallium will be nicer in this regard, since all fog will be
shader-driven, IIRC.
It would be *r
rs(): Don't know how to handle
> inputs 0x8
You're on an RS690, right?
Current fog handling 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 PROT
nd them?
>
> They are not yet available 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
-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 u
-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 dep
-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 s
Matthias Hopf wrote:
> I'm in the process of skimming through the 3D programming documentation
> of the r6xx chips. AMD announced on XDC 2008 to make it public, so it
> will show up pretty soon. It's one massive beast, more than 650 pages...
>
> Obviously, the first step to get 3D working on r6xx
37 matches
Mail list logo
