"Zou, Nanhai" writes:
> Hi,
> I have notice that in current driver implementation.
> When GL_DYNAMIC_DRAW flag is set in glBufferData, driver will not upload data
> to
> Graphics memory.
> Instead it will upload the _entire_ vertex/index buffer when
> glDrawElements/glDrawArray was cal
On Sat, 06 Nov 2010 09:23:06 +, Peter Clifton wrote:
> Fixes corruption with glBufferSubData on my machine,
>
> Can someone review and push?
Looks good. Thanks!
pgpQalh4TlIgQ.pgp
Description: PGP signature
--
The
On Sun, 28 Mar 2010 17:52:16 -0400, RALOVICH, Kristóf
wrote:
> Eric,
>
> please see the attached patch for piglit. The patch includes 2 new
> tests based on the demos I provided for mesa.
>
> Let me know if I can further help!
The main thing I'm concerned about is that you seem to be looking f
People that hang out on IRC have probably heard about my build system
work. One of the first steps I've been working on finishing is
splitting out the demos repository. We're currently distributing the
Mesa progs/ separately from the main Mesa distribution, and most people
aren't installing it, s
On Wed, 24 Mar 2010 11:10:47 -0400, RALOVICH, Kristóf
wrote:
> Brian,
>
> that was fast! Who do you think I should bug, to get these working on i965?
>
> Also as my time allows, I am planning to extend them with mouse input
> for orientation and arrow keys for moving to camera to become more
>
On Sat, 13 Mar 2010 16:52:36 +0200, Maxim Levitsky
wrote:
> This time I caught it early.
>
> 46450c1f3f93bf4dc96696fc7e0f0eb808d9c08a is first bad commit
> commit 46450c1f3f93bf4dc96696fc7e0f0eb808d9c08a
> Author: Eric Anholt
> Date: Wed Mar 10 17:38:33 2010 -0800
>
On Mon, 08 Mar 2010 14:50:45 -0800, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Eric Anholt wrote:
> > Module: Mesa
> > Branch: master
> > Commit: 7cbc4c07ee85782d5da3e2db3c4e072ca498ff07
> > URL:
> > http:/
On Thu, 4 Mar 2010 12:37:23 -0800, Jesse Barnes
wrote:
> Would anyone have objections if these lists moved to freedesktop.org?
> The recent thread with Linus about the drm pull request highlights the
> post lag and non-subscriber aspect of the current lists, and that
> leaves aside sf.net's horri
On Mon, 22 Feb 2010 08:38:49 -0800, Brian Paul wrote:
> Starting a new thread on this...
>
> Here's a proposal of things to remove from the Mesa tree.
>
> GLU:
> glu/mini
> glu/mesa
>
> GLUT:
> glut/fbdev
> glut/ggi
> glut/directfb
> glut/dos
> glut/mini
> glut/os2
>
> non-DRI drivers:
> drive
On Fri, 19 Feb 2010 16:16:32 -0800, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> While we're on the topic of removing dead weight, can we remove support
> for color index rendering? None of the hardware drivers support color
> index rendering, and color index renderi
On Thu, 11 Feb 2010 20:48:01 -0500, Kristian Høgsberg
wrote:
> Eric, I was hoping you could have a look at this one in particular.
Looks OK to me. I guess the DeleteAll is in case there was something
that's (accidentally) still referenced at screen close time?
pgpxE8E8euHCx.pgp
Description: P
On Thu, 11 Feb 2010 01:54:37 +0100, Marek Olšák wrote:
> Eric,
>
> yes, it does.
>
> I decided to resolve my precision issues using glDisable(GL_DITHER). The two
> patches disable dithering, the former in piglit and the latter in glean. I
> see no point in separating them to smaller ones but I c
On Sun, 7 Feb 2010 05:38:01 +0100, Marek Olšák wrote:
> The attached patch series relaxes precision requirements for 6 tests to pass
> on r300g.
>
> Please review/push.
I just pushed a change to do the r300relax type path always on cubemap
and fbo-cubemap. It sounds like the decision was that t
On Wed, 10 Feb 2010 21:50:14 +0100, Marek Olšák wrote:
> Hi,
>
> I noticed that quite a lot of piglit tests fail with swrast and softpipe. I
> was asked for sending my stats to ML so that people working on the software
> rasterizers are aware of that (I guess they already know). Please see this
>
On Sun, 7 Feb 2010 05:38:01 +0100, Marek Olšák wrote:
> The attached patch series relaxes precision requirements for 6 tests to pass
> on r300g.
>
> Please review/push.
Have you tried getting the glean components pushed to the glean project?
I'd rather not carry functional differences from glean
On Fri, 05 Feb 2010 13:01:50 -0800, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I'd like to remove a bunch of the visuals and fbconfigs exposed by the
> Intel drivers. There are several categories of visuals that are likely
> not useful to anyone. A couple of our t
On Thu, 4 Feb 2010 04:26:19 +0200, Pauli Nieminen wrote:
> fbo-3d was assuming npot texture support which caused
> glTexImage3D to fail with r200 driver.
Applied. Thanks!
pgpp9c3r2hDUh.pgp
Description: PGP signature
-
On Mon, 25 Jan 2010 13:04:10 +, José Fonseca wrote:
> mesa_7_7_branch and master are becoming quite different, because of all
> the gallium interface changes that have been going into master, so
> merging fixes from mesa_7_7_branch into master is becoming less and less
> of a trivial exercise.
On Wed, 06 Jan 2010 23:30:46 +0100, Pierre Willenbrock
wrote:
> Hi list,
>
> the first of these two patches fixes _mesa_meta_GenerateMipmap to update
> the viewport and projection matrix after changing the destination mipmap
> level. Before, pixels would get clipped to the boundaries of the
> or
On Tue, 05 Jan 2010 23:13:54 +0100, Roel Kluin wrote:
> These can never be true.
>
> Signed-off-by: Roel Kluin
> ---
> src/gallium/drivers/i965/brw_wm_emit.c |2 +-
> src/mesa/drivers/dri/i915/intel_tris.c |2 +-
> src/mesa/drivers/dri/i965/brw_wm_emit.c |2 +-
> 3 files changed,
On Sat, 12 Dec 2009 01:27:52 +0100, Maciej Cencora wrote:
> Dnia sobota, 21 listopada 2009 o 20:41:34 Maciej Cencora napisał(a):
> > Hi,
> >
> > attached patch fixes texturing/s3tc-texsubimage test. It passes now on
> > software rasterizer. R300 needs ~2% tolerance to pass.
> >
> > Regards,
> >
On Wed, 09 Dec 2009 08:19:11 -0700, Brian Paul wrote:
> Eric Anholt wrote:
> > On Tue, 08 Dec 2009 23:38:22 -0800, Ian Romanick
> > wrote:
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA1
> >>
> >> Eric Anholt wrote:
> >>>
On Tue, 08 Dec 2009 23:38:22 -0800, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Eric Anholt wrote:
> > ---
> > src/mesa/drivers/dri/intel/intel_buffers.c| 21 +
> > src/mesa/drivers/dri/intel/intel_exte
---
src/mesa/drivers/dri/intel/intel_buffers.c| 21 +
src/mesa/drivers/dri/intel/intel_extensions.c |1 +
2 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_buffers.c
b/src/mesa/drivers/dri/intel/intel_buffers.c
index 6b1
I'd like to get it either into this release or the point release after it --
giving people the tools to use OpenGL appropriately seems important.
(idr noted that we don't need the extension enable in the driver, since it's
always there)
This replaces the st_cb_get wrapper around glGet with using the FB's fields.
---
src/mesa/sources.mak|1 -
src/mesa/state_tracker/st_cb_fbo.c | 16 ++
src/mesa/state_tracker/st_cb_get.c | 97 ---
src/mesa/state_tracker/st_cb_get.h |
The spec quite reasonably says it's dependent on the current read surface,
so it doesn't look like a Const.
---
src/mesa/main/context.c|4
src/mesa/main/framebuffer.c|5 +
src/mesa/main/get.c| 16
src/mesa/main/get_gen.py
On Fri, 4 Dec 2009 02:24:26 -0800, Kenneth Graunke
wrote:
> On Thursday 03 December 2009 12:47:36 Brian Paul wrote:
> [snip]
> > I've been meaning to go over imports.[ch] and make a bunch of the
> > wrapper functions inlines.
> >
> > A lot of the wrappers aren't needed any more. Back before val
On Fri, 2009-10-30 at 19:10 -0600, Brian Paul wrote:
> Eric Anholt wrote:
> > Module: Mesa
> > Branch: master
> > Commit: 7c8bed62e0165a0be3363f7abf81bf9e30341e00
> > URL:
> > http://cgit.freedesktop.org/mesa/mesa/commit/?id=7c8bed62e0165a0be3363f7abf81bf9e3034
C_NUMERIC, "C");
> > strtod(...);
> > setlocale(LC_NUMERIC, oldLocale);
> >
> > However, I suspect that there would be a nasty performance penalty for
> > repeatedly switching the locale, as well as there being multi-threading
> > considerati
Between these two patches, cairo-gl firefox's runtime drops from 120
seconds to under 90 seconds. Can anyone justify these flushes?
--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only develo
---
src/mesa/main/fbobject.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index a73a765..6e767bb 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -1207,9 +1207,6 @@ _mesa_BindFramebufferEXT(GLe
This reverts commit df058298e1570eea8712f9bb051f674fab2eaf24. It didn't
explain why it was required, doesnt appear to be required, and is a major
performance penalty for cairo-gl firefox.
Conflicts:
src/mesa/main/fbobject.c
---
src/mesa/main/fbobject.c | 26 --
On Fri, 2009-09-11 at 10:37 -0700, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Eric Anholt wrote:
> > Module: Mesa
> > Branch: master
> > Commit: 7c0152fbaeb21ab423a9de339b85c54d1713432b
> > URL:
> > http:/
buffer_range semantics. Looks like a quick fix in
st_bufferobj_map_range.
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
-
On Wed, 2009-08-12 at 13:00 +, Nicolas Cadio wrote:
>
> Else , somebody can explain me how to use the function glXSwapBuffers
> with a vertical synchronisation ?
Update your 2D driver to version 2.8.0.
--
Eric Anholt
e...@anholt.net eric.anh...@
This saves mapping the index buffer to get a bounds on the indices that
drivers just drop on the floor in the VBO case (cache win), saves a bonus
walk of the indices in the CheckArrayBounds case, and other miscellaneous
validation. On intel it's a particularly a large win (50-100% in my app)
becau
---
src/mesa/drivers/dri/i965/brw_vs_emit.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vs_emit.c
b/src/mesa/drivers/dri/i965/brw_vs_emit.c
index 722307c..ade156e 100644
--- a/src/mesa/drivers/dri/i965/brw_vs_emit.c
+++ b/src/mesa/driver
I don't have a real testcase for this (is there one handy?), so I figured I'd
post it to the list. Does it help what you were looking at, by chance?
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008
This fixes jerkiness in doom3 and other apps since the kernel change to
throttle less absurdly, which led to a thundering herd of frames.
---
include/GL/internal/dri_interface.h| 12
src/glx/x11/dri2_glx.c |5 +
src/glx/x11/dri_common.c
This fixes the mesa readpix demo with scale and bias enabled. I can't
justify why it should, though -- anyone have any explanation here?
Bug #20262.
---
src/mesa/drivers/dri/intel/intel_pixel_copy.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/src/mesa/driv
they test, so please apply.
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
On Tue, 2009-06-30 at 16:59 +0200, Michel Dänzer wrote:
> On Mon, 2009-06-29 at 10:57 -0700, Eric Anholt wrote:
> >
> > This code was originally introduced with the i915tex code dump, so it's not
> > clear what it was there for.
>
> What exactly do you mean by
On Mon, 2009-06-29 at 19:11 +0100, Keith Whitwell wrote:
> On Mon, 2009-06-29 at 10:57 -0700, Eric Anholt wrote:
> > Module: Mesa
> > Branch: master
> > Commit: de447afff26706e3bf8bdcd5cfb8b1daf49b4b21
> > URL:
> > http://cgit.fre
On Fri, 2009-06-19 at 17:58 +0200, Michel Dänzer wrote:
> On Wed, 2009-06-17 at 21:03 -0700, Eric Anholt wrote:
> > Module: Mesa
> > Branch: master
> > Commit: 0f328c90dbc893e15005f2ab441d309c1c176245
> > URL:
> > http://cgit.fre
d then
enable real VBO usage for immediate mode.
The alternative for immediate mode would be implementing the ranged
buffer mapping extension, which lets the VBO module do the right thing.
I'm concerned that we have no testcases
On Fri, 2009-05-15 at 16:59 -0700, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Eric Anholt wrote:
> > Module: Mesa
> > Branch: master
> > Commit: 0307e609aa3e707eeb40051bd664d36f2340ba9b
> > URL:
> > http:/
et
> >>> time.
> >>
> >> I've been experiencing this with some of our internal test cases. The
> >> killer seems to be programs that do lots of state changes. glxgears
> >> does almost no state changes, so it's not surprising tha
own.
>
> It seemed to be a timing issue as the app would no longer be using all
> cpu of a single core (noticeably less cpu than on the 7.4-branch
> version), and paradoxically, running another cpu intensive task would
> result in the fps increasing. I'll do some more testi
On Wed, 2009-04-01 at 22:15 -0700, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Eric Anholt wrote:
> > On Wed, 2009-04-01 at 18:30 -0700, Ian Romanick wrote:
> >> Track whether or not front-buffer rendering may have occured. If
> >&
ering has occured to the drawable's front buffer.
> +*
> +* This is used in the DRI2 case to detect that glFlush should also copy
> +* the contents of the fake front buffer to the real front buffer.
> +*/
> + GLboolean front_buffer_dirty;
> +
> drm_clip_rect_
> pretty.
Yeah, I also recently made one test do read of back before swap after
running into the DRI2 problem. It's a lot nicer anyway imo since that
means that nothing else on the screen can interfere with the results.
Well, unless you're doing DRI1, but then you get what you des
+ break;
> + }
> + if (i == count) {
> + *width = pdraw->width;
> + *height = pdraw->height;
> + *out_count = pdraw->bufferCount;
> + return pdraw->buffers;
> + }
> +}
> +
> buffers = DRI2GetBuffers
On Fri, 2009-03-20 at 19:23 +0100, Michel Dänzer wrote:
> On Fre, 2009-03-20 at 10:45 -0700, Eric Anholt wrote:
> > Module: Mesa
> > Branch: master
> > Commit: 66175aac7609ad314f25fbdff0d3958af310dc24
> > URL:
> > http://cgit.fre
On Thu, 2009-03-19 at 14:34 -0700, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Eric Anholt wrote:
> > This requires upgrading the interface so that the argument to
> > glXBindTexImageEXT isn't just dropped on the floor. Note that this o
This requires upgrading the interface so that the argument to
glXBindTexImageEXT isn't just dropped on the floor. Note that this only
fixes the accelerated path on Intel, as Mesa's texture format support is
missing x8r8g8b8 support (right now, GL_RGB textures get uploaded as a8r8gb8,
but in this c
I've written
> them to use GLEW. Is that okay? I prefer GLEW over just defining
> GL_GLEXT_PROTOTYPES or trying to re-re-re-re-invent the wheel in
> piglit-util.c.
I'd love to see GLEW added. I was just writing a test for EXT_tfp, and
couldn't use glut for initializatio
On Tue, 2009-03-10 at 21:53 -0700, Ian Romanick wrote:
> commit f085147258713741895945dcb81fdb251bb6c9cc
> Author: Eric Anholt
> Date: Thu Mar 5 08:25:22 2009 -0800
>
> intel: Remove a gratuitous MI_FLUSH after clearing with a blit.
I'd rather not do this one, to be
On Thu, 2009-02-26 at 09:04 -0800, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Eric Anholt wrote:
>
> > diff --git a/src/mesa/drivers/dri/intel/intel_pixel_bitmap.c
> > b/src/mesa/drivers/dri/intel/intel_pixel_bitmap.c
> > index
This showed up in bug #19911: When all VBs were disabled (because we were
getting a DrawArrays with no arrays enabled, which was a bug), the VP
got flagged as having no InputsRead. We would proceed to emit a VB state
packet with -1 length, and the parser got angry with us. This doesn't fix
the pr
Otherwise, a pointer greater than the size would underflow and give a large
maximum element.
---
src/mesa/main/varray.c | 16 +++-
1 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/src/mesa/main/varray.c b/src/mesa/main/varray.c
index 106252e..3127c03 100644
--- a/src/m
The 2.0 spec doesn't make things extremely clear, but expresses itself in
pseudocode: If the vertex array isn't enabled, then nothing is called that
provokes drawing. The manifestation of this bug was that a client drawing
with no arrays enabled would get into the driver with a request to
draw wit
to glean-master,
then merge that. This keeps the next victim from having to re-resolve
conflicts.
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
idr said that in his review swrast was ready for it, and the 965 driver is
advertising it already though it has been resulting in many crashes due to
arrays using these defines not being big enough.
---
src/mesa/main/config.h |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff
move it somewhere appropriate in Mesa.
sauerbraten's a nice open-source game that works the driver a lot harder
than openarena does.
When you get to fbos, the gl branch of my cairo tree plus the gl branch
of my cairogears tree is mostly memory management and fbo handling right
now (unt
e. Has the exact cause in the server
> been identified?
There was some seriously broken code in the X Server:
commit 5100d829a4d71ce4a9fbc2b81694a1fb90066ccf
Author: Eric Anholt
Date: Mon Feb 2 10:13:46 2009 -0800
glx: Don't match fbconfigs to visuals with mismatched channel masks.
This is about a 5% win from doing two glViewport()s per frame in openarena.
---
include/GL/internal/dri_interface.h|8 +-
src/glx/x11/dri2_glx.c | 41
src/glx/x11/glxclient.h|1 +
src/mesa/drivers/dri/intel/
On Fri, 2009-01-30 at 00:03 +, Peter Clifton wrote:
> On Thu, 2009-01-29 at 15:08 -0800, Eric Anholt wrote:
> > We can support any combination of (a8r8g8b8, x8r8g8b8, r5g6b5) x
> > (z0,z24,z24s8)
> > on either class of chipsets. The only restriction is no mixing bpp when
We can support any combination of (a8r8g8b8, x8r8g8b8, r5g6b5) x (z0,z24,z24s8)
on either class of chipsets. The only restriction is no mixing bpp when also
mixing tiling. This shouldn't be occurring currently.
---
src/mesa/drivers/dri/common/utils.c |3 +-
src/mesa/drivers/dri/common/
There was a note in state.c about _Active deserving to die, and there were
potential issues with it due to i965 forgetting to set _UseTexEnvProgram.
Removing both simplifies things.
---
src/mesa/drivers/dri/i915/i915_context.c |1 -
src/mesa/drivers/dri/i915/i915_state.c|2 +-
On Wed, 2009-01-07 at 10:07 +, Keith Whitwell wrote:
> On Wed, 2009-01-07 at 01:49 -0800, Eric Anholt wrote:
> > Here's a pair of patches I came up with tonight when looking at #18074 and
> > #14503. The first looks like we might end up with junk in a temporary if
&g
Bug #18074
---
src/mesa/drivers/dri/i915/i915_context.c |3 +-
src/mesa/drivers/dri/i915/i915_context.h |1 +
src/mesa/drivers/dri/i915/i915_fragprog.c | 82 +
src/mesa/drivers/dri/i915/i915_reg.h |4 +-
4 files changed, 76 insertions(+), 14 deletio
This means we're now overestimating liveliness of regs, but better than the
other way around. It also makes fixing #18074 easier.
---
src/mesa/drivers/dri/i915/i915_fragprog.c | 22 +-
1 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/
Here's a pair of patches I came up with tonight when looking at #18074 and
#14503. The first looks like we might end up with junk in a temporary if
we wrote it, did a masked texld, then wrote to it again with a destination
write mask.
The second creates a mapping from register->Index to hardware
We'd come up with a negative remainder, while we were looking for the positive
version of it in the loop conditional. And, since the "did we hit our target"
break was disabled for the target_msc == 0 ("Just make the divisor/remainder
work") path, we'd never exit.
Simplify the code by just using i
Mesa core also has this bug for CopyTexSubImage.
---
src/mesa/drivers/dri/intel/intel_pixel_copy.c |4 ++--
src/mesa/drivers/dri/intel/intel_tex_copy.c |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_pixel_copy.c
b/src/mesa/drivers/
Here's a patch series I'm working on for fixing #19139. The OGLC testcase
fails still, and I think I'm going to just write myself some nice little
visual testcases for piglit instead of continuing to guess at what's wrong.
-
---
src/mesa/drivers/dri/intel/intel_pixel_bitmap.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_pixel_bitmap.c
b/src/mesa/drivers/dri/intel/intel_pixel_bitmap.c
index 4988230..38581d9 100644
--- a/src/mesa/drivers/dri/intel/intel_pi
---
src/mesa/drivers/dri/intel/intel_pixel_bitmap.c |3 +++
src/mesa/drivers/dri/intel/intel_pixel_copy.c |3 +++
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_pixel_bitmap.c
b/src/mesa/drivers/dri/intel/intel_pixel_bitmap.c
index e3ce14
pent 60% of its 45-second
startup time with a hot cache in mesa's program parsing, and it doesn't
have that many programs. However, I'd love to see a conversion of
mesa's ARB_[fv]p parsing to lex/yacc before we built a complicated
infrastructure to work around the performance
This was another opportunity to either get clipped to screen size or not get
clipped enough and draw outside of object boundaries.
---
src/mesa/drivers/dri/intel/intel_pixel_copy.c | 104 +---
1 files changed, 56 insertions(+), 48 deletions(-)
diff --git a/src/mesa/drivers/dr
To follow is a patch series started by looking into #18914. With it
fbo_firecube runs, and I'm farther through the FBO testcases in our oglconform
than ever before, in both hardware and software. I'm especially interested in
review on ctx->Driver.GenerateMipmap interface and whether having
SGIS_g
Bug #18914. Fixes fbo_firecube hang due to drawing outside the FBO bounds.
Thanks to Pierre Willenbrock for debugging the issue.
---
src/mesa/drivers/dri/intel/intel_pixel_bitmap.c | 72 --
1 files changed, 39 insertions(+), 33 deletions(-)
diff --git a/src/mesa/drivers/dri
The ctx->Driver.GenerateMipmap() hook only expects cubemap face enums, not
CUBE_MAP_ARB, so walk all faces when we encounter that. Fixes oglconform
fbo.c segfault with both swrast and i965 drivers.
---
src/mesa/main/fbobject.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
Fixes a segfault in oglconform fbo.c test.
---
src/mesa/drivers/dri/intel/intel_fbo.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
index fce5e36..7453b96 100644
--- a/src/mesa/drive
The images aren't mapped at this point, so we want the generic Mesa path for
GenerateMipmapEXT that does the mapping/unmapping for us. Ideally Mesa would
just call it for us.
---
src/mesa/drivers/dri/intel/intel_tex_copy.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/
Later primitives, even if they caused a full state validate, wouldn't check
that there was enough space in the batchbuffer, occasionally triggering the
sanity check. We also skipped the aperture space check, even if it would
mean bringing in new programs and associated state.
---
src/mesa/drivers
e trouble. I haven't looked to try and figure out what's going
> on.
>
> commit 59b2c2adbbece27ccf54e58b598ea29cb3a5aa85
> Author: Eric Anholt <[EMAIL PROTECTED]>
> Date: Fri Oct 24 13:02:21 2008 -0700
>
> i965: Fix check_aperture calls t
It shouldn't offer anything new over what's in the docs (except for G4X notes),
but here it's all in one place.
---
src/mesa/drivers/dri/i965/brw_urb.c | 39 ++-
1 files changed, 38 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_urb.c
b
As far as I can read in the docs, VS threads can be 1:1 with the pairs of
VUE handles allocated for them. Also, G4X can run twice as many threads as
before (though we won't unless the we bump the preferred URB entries for VS).
---
src/mesa/drivers/dri/i965/brw_vs_state.c | 16 ++--
I spent a while today reading up on the URB and thread management issues on the
965, and I think I spotted a few bugs in the code. I'm hoping that someone
else can review the fixes for correctness, as I'm still not entirely convinced
of the changes. I separated them out for easier bisecting.
The
We were dividing the number of URB entries by two to get number of threads,
which looks suspiciously like a copy'n'paste-o from brw_vs_state.c. Also, the
maximum number of threads is 24, not 12.
---
src/mesa/drivers/dri/i965/brw_sf_state.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions
The clip thread could potentially deadlock when processing tristrips since
being moved back to dual-thread mode, as the two threads could each have 4 VUEs
referenced and not be able to allocate another one since SF processing
wasn't able to continue (needing 5 entries before it freed 2).
In constra
---
src/mesa/drivers/dri/i965/brw_wm_state.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_wm_state.c
b/src/mesa/drivers/dri/i965/brw_wm_state.c
index 61fe97a..fd46161 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_state.c
+++ b/src/
On Wed, 2008-10-22 at 09:39 +0200, Michel Dänzer wrote:
> On Tue, 2008-10-21 at 12:07 -0700, Eric Anholt wrote:
> > This fixes vblank support for a 32-bit X Server on a 64-bit kernel.
>
> Thanks for tackling this, mea culpa for not testing it with 32 on 64 in
> the first place
Signed-off-by: Eric Anholt <[EMAIL PROTECTED]>
---
drivers/gpu/drm/drm_drawable.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_drawable.c b/drivers/gpu/drm/drm_drawable.c
index 4a794d8..80be1ca 100644
--- a/drivers/gpu/drm/drm_drawable.c
This fixes vblank support for a 32-bit X Server on a 64-bit kernel.
Signed-off-by: Eric Anholt <[EMAIL PROTECTED]>
---
drivers/gpu/drm/drm_ioc32.c | 34 ++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_ioc32.c b/drive
gt; contexts. I didn't think this through, but it seems like having the bufmgr in
> the GL context is incorrect?
Correct, as far as I can tell. It's on the list of things to fix for
Intel that other issues have kept us from getting to so far.
--
Eric Anholt
[EMAIL PROTE
drm external kernel modules tree -- /git/mesa/libdrm perhaps. Then
we don't have to worry about whether the driver can be built on specific
kernels when we're just trying to get the userland component ready.
I suppose the alternative would be for us to just back o
the most
7.1-ish and include GEM on top of that. But the timeframe for that is
the next couple of months, not the next couple of days.
--
Eric Anholt
[EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
--
1 - 100 of 120 matches
Mail list logo
