On 13.08.2009 12:19, Michel Dänzer wrote:
> On Wed, 2009-08-12 at 11:31 -0700, Eric Anholt wrote:
>> Module: Mesa Branch: master Commit:
>> e643bc5fc7afb563028f5a089ca5e38172af41a8 URL:
>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=e643bc5fc7afb563028f5a089ca5e38172af41a8
>>
>>
>> Author: E
http://bugs.freedesktop.org/show_bug.cgi?id=8087
Ian Romanick changed:
What|Removed |Added
CC||i...@freedesktop.org
Component|Ot
We allocate and free dma buffers all the time that accounts for large part
of system time in OGL applications.
First patch fixes allocation problem by keeping buffer objects in linked
list until they have been unused for 100 flushes when they are freed back to
kernel.
2nd patch is simple bug fix w
http://bugs.freedesktop.org/show_bug.cgi?id=22567
Ian Romanick changed:
What|Removed |Added
AssignedTo|mesa3d- |i...@freedesktop.org
|d
http://bugs.freedesktop.org/show_bug.cgi?id=23311
Brian Paul changed:
What|Removed |Added
AssignedTo|mesa3d- |sitewrangl...@lists.freedesk
http://bugs.freedesktop.org/show_bug.cgi?id=23311
--- Comment #1 from Tom Fogal 2009-08-14 11:02:48 PST
---
Created an attachment (id=28636)
--> (http://bugs.freedesktop.org/attachment.cgi?id=28636)
GPG public key
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
http://bugs.freedesktop.org/show_bug.cgi?id=23311
Summary: Account request for tfogal
Product: Mesa
Version: unspecified
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Compone
On Fri, Aug 14, 2009 at 09:49:18AM -0600, Brian Paul wrote:
> OK, the problem with these patches (as Keith commented on) is that
> the build is broken between the patches. That makes git-bisect
> difficult.
> How about we combine these patches into one big patch that doesn't
> break the build?
The
On Fri, Aug 14, 2009 at 05:08:00PM +0100, Jakob Bornecrantz wrote:
> I don't know how well creating two or more displays from the same
> driver works with the old/new API. I'm guessing with the old one it
> would load the driver twice. From what I can see from the code it
> looks like your does as
tom fogal wrote:
> Brian Paul writes:
>> tom fogal wrote:
>>> Brian Paul writes:
Dan Nicholson wrote:
> On Thu, Aug 13, 2009 at 7:10 PM, tom fogal wrote:
>> Brian Paul writes:
>>> tom fogal wrote:
Perhaps we could have [...] a --with-max-width=16384 [which] could
>>
Brian Paul writes:
> tom fogal wrote:
> > Brian Paul writes:
> >> Dan Nicholson wrote:
> >>> On Thu, Aug 13, 2009 at 7:10 PM, tom fogal wrote:
> Brian Paul writes:
> > tom fogal wrote:
> >> Perhaps we could have [...] a --with-max-width=16384 [which] could
> >> accomodate our ca
tom fogal wrote:
> Brian Paul writes:
>> Dan Nicholson wrote:
>>> On Thu, Aug 13, 2009 at 7:10 PM, tom fogal wrote:
Brian Paul writes:
> tom fogal wrote:
>> Perhaps we could have [...] a --with-max-width=16384 [which] could
>> accomodate our case without inflating the standard bu
José Fonseca pisze:
> On Thu, 2009-07-30 at 02:52 -0700, Micha?? Kr??l wrote:
>
>> Module: Mesa
>> Branch: master
>> Commit: b724dd28e24ec1c38af1082f5e16cd9a12d1653d
>> URL:
>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=b724dd28e24ec1c38af1082f5e16cd9a12d1653d
>>
>> Author: Michal Krol
Brian Paul writes:
> Dan Nicholson wrote:
> > On Thu, Aug 13, 2009 at 7:10 PM, tom fogal wrote:
> >> Brian Paul writes:
> >>> tom fogal wrote:
> Perhaps we could have [...] a --with-max-width=16384 [which] could
> accomodate our case without inflating the standard buffer sizes.
[snip]
>
Chia-I Wu wrote:
> Hi,
>
> This patch series tries to clarify the roles of EGLDriver and
> EGLDisplay. It was also mentioned in another thread, and depend on the
> driver API overhaul.
>
> The rationale behind the change is every driver provides only a single
> EGLDriver instance. That instance
Chia-I Wu wrote:
> On Fri, Aug 14, 2009 at 09:23:22AM -0600, Brian Paul wrote:
>> I think I'm getting lost among all your patches. The first one in
>> this series doesn't cleanly apply. Maybe I missed a previous patch?
> Yes, it got moderated because of the size. I have attached a gzipped
> tarb
On 08/14/2009 04:39 PM, Alex Deucher wrote:
> On Fri, Aug 14, 2009 at 11:29 AM, Terry Barnaby wrote:
>> On 08/14/2009 03:56 PM, Alex Deucher wrote:
>>> On Fri, Aug 14, 2009 at 4:44 AM, Terry Barnabywrote:
I am using the latest drm/xf86-video-ati/mesa code from git on a Fedora
11 base
On Fri, Aug 14, 2009 at 11:29 AM, Terry Barnaby wrote:
> On 08/14/2009 03:56 PM, Alex Deucher wrote:
>>
>> On Fri, Aug 14, 2009 at 4:44 AM, Terry Barnaby wrote:
>>>
>>> I am using the latest drm/xf86-video-ati/mesa code from git on a Fedora
>>> 11 base
>>> platform. There was a problem with Blende
On Fri, Aug 14, 2009 at 09:23:22AM -0600, Brian Paul wrote:
> I think I'm getting lost among all your patches. The first one in
> this series doesn't cleanly apply. Maybe I missed a previous patch?
Yes, it got moderated because of the size. I have attached a gzipped
tarball of it in this mail.
>
On 08/14/2009 03:56 PM, Alex Deucher wrote:
> On Fri, Aug 14, 2009 at 4:44 AM, Terry Barnaby wrote:
>> I am using the latest drm/xf86-video-ati/mesa code from git on a Fedora 11
>> base
>> platform. There was a problem with Blenders menu's being painted in
>> black/white,
>> that has now been fi
Chia-I Wu wrote:
> Hi,
>
> This patch series tries to clarify the roles of EGLDriver and
> EGLDisplay. It was also mentioned in another thread, and depend on the
> driver API overhaul.
>
> The rationale behind the change is every driver provides only a single
> EGLDriver instance. That instance
Chia-I Wu wrote:
> On Fri, Aug 14, 2009 at 03:49:23PM +0100, Jakob Bornecrantz wrote:
>> NACK, it is very seldom allowed for any GL api to cause the program
>> to crash due to inputs to any of the exposed calls. According to the
>> specification any invalid EGLDisplay's or EGLSurface's should raise
On Fri, Aug 14, 2009 at 03:49:23PM +0100, Jakob Bornecrantz wrote:
> NACK, it is very seldom allowed for any GL api to cause the program
> to crash due to inputs to any of the exposed calls. According to the
> specification any invalid EGLDisplay's or EGLSurface's should raise
> the appropriate EGL
Dan Nicholson wrote:
> On Thu, Aug 13, 2009 at 7:10 PM, tom fogal wrote:
>> Brian Paul writes:
>>> tom fogal wrote:
Is there interest in bumping [the MAX_WIDTH/HEIGHT] limit up? Are
there issues we're not considering when we do this?
Perhaps we could have [...] a --with-max-wi
On Fri, Aug 14, 2009 at 4:44 AM, Terry Barnaby wrote:
> I am using the latest drm/xf86-video-ati/mesa code from git on a Fedora 11
> base
> platform. There was a problem with Blenders menu's being painted in
> black/white,
> that has now been fixed (Thanks to whoever !). However, there is still a
On Fri, Aug 14, 2009 at 03:03:02PM +0100, Keith Whitwell wrote:
> Regarding 0006-progs-egl-Fix-compilation-error-of-demo3.patch:
> In general it is preferable not to introduce compilation errors into the
> git history, at least knowingly. Can you respin your patch series to
> not introduce the err
Tobias Doerffel wrote:
> Hi,
>
> Am Samstag, 8. August 2009 01:01:46 schrieben Sie:
>> Using drm_i915_sarea_t instead of struct drm_i915_sarea seems to be
>> a common standard now, therefore fix it also in intel_context
>> structure. Additionally this silences a compiler warning:
>>
>> intel_swapb
Chia-I Wu wrote:
> Hi,
>
> This patch series aims to remove eglhash.c and eglhash.h. Consider the
> speed of eglHashTable in its current form, and that there are usually
> only a small number of displays/surfaces/contexts, it should be faster
> to simply use lists. It also gives cleaner code.
>
Chia-I Wu wrote:
> On Thu, Aug 13, 2009 at 01:42:13PM -0700, Nicholas Lowell wrote:
>> I go from proper execution to "symbol lookup error:
>> mesa/lib/egl_softpipe.so: undefined symbol: st_get_current when upgrading
>> from mesa-54a7115fc27c640e2b3f1a362e8e07aac220556d to mesa-
>> 0153614cb0ce52e5
On Fri, 2009-08-14 at 06:50 -0700, Chia-I Wu wrote:
> Hi,
>
> This patch series aims to remove eglhash.c and eglhash.h. Consider the
> speed of eglHashTable in its current form, and that there are usually
> only a small number of displays/surfaces/contexts, it should be faster
> to simply use lis
Hi,
This patch series aims to remove eglhash.c and eglhash.h. Consider the
speed of eglHashTable in its current form, and that there are usually
only a small number of displays/surfaces/contexts, it should be faster
to simply use lists. It also gives cleaner code.
It depends on the last two pat
Here is code to make r300 predict state emission size. Testing is "It
compiles it works style". So code might still have bugs.
I didn't change primitive emission prediction code. I think that someone
with better knowledge of r300 rendering paths should look at it if there
should be some improvemen
Signed-off-by: Pauli Nieminen
---
.../drivers/dri/r300/compiler/r3xx_vertprog_dump.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/src/mesa/drivers/dri/r300/compiler/r3xx_vertprog_dump.c
b/src/mesa/drivers/dri/r300/compiler/r3xx_vertprog_dump.c
index 39c
On Thu, 2009-07-30 at 02:52 -0700, Micha?? Kr??l wrote:
> Module: Mesa
> Branch: master
> Commit: b724dd28e24ec1c38af1082f5e16cd9a12d1653d
> URL:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=b724dd28e24ec1c38af1082f5e16cd9a12d1653d
>
> Author: Michal Krol
> Date: Thu Jul 30 10:12:09 2
Hi,
Am Samstag, 8. August 2009 01:01:46 schrieben Sie:
> Using drm_i915_sarea_t instead of struct drm_i915_sarea seems to be
> a common standard now, therefore fix it also in intel_context
> structure. Additionally this silences a compiler warning:
>
> intel_swapbuffers.c: In function `intelFixupV
Hi,
This patch series tries to clarify the roles of EGLDriver and
EGLDisplay. It was also mentioned in another thread, and depend on the
driver API overhaul.
The rationale behind the change is every driver provides only a single
EGLDriver instance. That instance is used to drive any number of
d
On 08/14/2009 09:44 AM, Terry Barnaby wrote:
> I am using the latest drm/xf86-video-ati/mesa code from git on a Fedora 11
> base
> platform. There was a problem with Blenders menu's being painted in
> black/white,
> that has now been fixed (Thanks to whoever !). However, there is still an
> issu
I am using the latest drm/xf86-video-ati/mesa code from git on a Fedora 11 base
platform. There was a problem with Blenders menu's being painted in
black/white,
that has now been fixed (Thanks to whoever !). However, there is still an issue
where the menus and buttons are displayed offset about
38 matches
Mail list logo
