[AMD Official Use Only - Internal Distribution Only]
The one suggestion I saw that definitely seemed worth looking at was adding
download caches if the larger CI systems didn't already have them.
Then again do we know that CI traffic is generating the bulk of the costs ? My
guess would have bee
))Sure! We support both OpenGL 2.1 and OpenGL ES 2.0 as back-ends, and ES is
the best since it's closest to the WebGL API (using OpenGL 2.1 forces us to do
quite costly emulation in a few cases, especially when drawing with vertex
attrib 0 array disabled).
))Naive question --- how do we get a G
))We don't want to require GL_ARB_ES2_compatibility. So i'll try to see how I
can emulate this functionality on desktop OpenGL.
Hi Benoit,
Would you still use native GL ES support if available on the system ? GL ES is
still the preferred path for the ATI/AMD proprietary drivers.
Thanks,
JB
__
>>I'm really not sure of that. I think one reason dx10 did this is because
applications mostly did that anyway - at least for subsequent frames
pretty much all the state they are using is going to be the same one as
used on the previous frame.
That is probably an important point -- there may not
>>Why do you think it's faster to create and use a new state rather than search
>>in the hash cache and reuse this? I was under the impression (this being a
>>dx10 paradigm) even hw is quite optimized for this (that is, you just keep
>>all the state objects on the hw somewhere and switch between
I believe the AMD implementation also runs on CPUs, not just GPUs.
Look for "Stream SDK" at amd.com.
- Original Message -
From: mesa-dev-bounces+john.bridgman=amd@lists.freedesktop.org
To: mesa-dev@lists.freedesktop.org
Sent: Thu Jul 01 15:00:13 2010
Subject: Re: [Mesa-dev] openc
> idr wrote :
> Before we changed to this model, Brian and I were basically
> the only ones that cherry-picked stuff back. It was
> difficult to figure out which changes from three months ago
> should be brought from master to stable. I'll point out that
> we basically had *no* process, and
> Brian Paul
...
> BTW, your last sentence can go either way. From my point of view
> it's: "Its a lot easier to just fix bugs on the 7.8 branch on
> those machines, and when you get around to it later merging
> the changes back into master, and dedicating a day to
> retesting master on as many
> From: ... Brian Paul
> Sent: Friday, April 30, 2010 12:17 AM
> To: Dave Airlie
> Cc: mesa-dev@lists.freedesktop.org
...
> If you're concerned about producing a stable driver, why
> aren't you making more fixes to the 7.8/stable branch,
> whether by cherry picking or whatever? That's the whole
There might be a clue in the dmesg output.
This is looking less like a mesa dev issue - is there a better list for this ?
> -Original Message-
> From: Alex Buell [mailto:alex.bu...@munted.org.uk]
> Sent: Tuesday, April 20, 2010 12:29 PM
> To: Bridgman, John
&g
Looks like the driver isn't finding enough memory for the offscreen buffer.
Maybe try 16-bit pixel depth instead of 24 ?
> -Original Message-
> From: mesa-dev-boun...@lists.freedesktop.org
> [mailto:mesa-dev-boun...@lists.freedesktop.org] On Behalf Of
> Alex Buell
> Sent: Monday, April 19
John Bridgman wrote :
> OK, file this under "be careful what you wish for"...
>
> It turns out that while the programming model of Evergreen is
> very similar to 7xx, the register offsets are totally
> different, which has been causing a bunch of header file pain
> trying to merge Evergreen sup
> On Tue, Apr 13, 2010 at 11:47 PM, Keith Whitwell
> wrote:
..
> Hmm, on gmail this is threaded as if a comment on John's "be careful
> what you wish for" post - which wasn't the intention. My own fault
> for top-posting.
Probably my fault - I subscribed to the list midway through the discussi
JB>>The reality is that we don't have a conveniently timed architectural break
to force the writing of an all new driver, and I imagine you don't either, so
we're all going to have to "ooze" across to Gallium3D.
OK, file this under "be careful what you wish for"...
It turns out that while the p
>No, it was true even as the first Gallium code was landing in the
>repo. Rewriting everything is always painful, and we already had
>plenty of other tasks to keep us busy (see Dave's mail) and cause pain
>for everyone. In hindsight, maybe it wouldn't have been any worse than
>what we went throug
15 matches
Mail list logo
