Age | Commit message (Collapse) | Author |
|
This is the Mesa portion of the pipe & plane disambiguation. Mesa needs to use
the new assumptions about plane vs. pipe mappings and should use the new SAREA
field names to avoid confusion.
|
|
|
|
Not doing this could cause the buffers to leak under some circumstances.
|
|
Just always align texture pitch to multiples of 64 bytes for now, pending a
more sophisticated scheme to do it only when really necessary.
|
|
|
|
Pull apart some key packets into individual fields and print sanely.
|
|
|
|
which make small textures(4x4,2x2,1x1) work well.
|
|
|
|
|
|
(untested)
|
|
Must not change to/from swrast after Render.Start or bad things will happen.
(Driver will still somewhat incorrectly report an implementation error,
and apps can't really figure out if a prog is natively supported as validation
is later - could try doing it earlier to give some hint at least, even though
native status may still change later due to fog etc.)
|
|
Make sure that we bind the right buffer (draw or read) when rebinding
the window framebuffer (the api doesn't allow binding different draw and
read buffers at the same time, but the default window framebuffer is basically
2 fb objects, one for read, one for write, which can be different). Pass both
of these two down the driver api (no driver uses this right now).
|
|
xdemos/shape)
|
|
|
|
The previous procedure would often result in a GPU lockup.
|
|
This avoids superfluous waits for vblank timing out under some circumstances.
|
|
The t_dd_tritemp.h code can emit GL_QUADS primitives. We need to catch
that case to determine if polygon stipple should be enabled.
Fixes bug reported by Carlos Diógenes on 4 July 2007.
|
|
Need to turn off FRAG_BIT_COL0 in swrast->_ActiveAttribMask when doing
glRead/CopyPixels to prevent the user's colors from getting overwritten
when a fragment program is active.
This was happening in the DRI drivers when MaintainTexEnv program was
used (the texenv fragment program was enabled when _swrast_DrawPixels was
called).
This still isn't an ideal solution, but fixes things for now.
|
|
It's OK to use _TexEnvProgram regardless of the texture state, but if fog
is also enabled, the fragment program is lacking the actual fog computation
so fogging doesn't appear.
Fixing this might involve a new _MaintainFogProgram field and related code.
For now, just disable the _TexEnvProgram and let swrast handle everything.
|
|
|
|
|
|
|
|
The previous approach could lead to crashes in FBO code that dereferences the
miptree struct pointer unconditionally.
|
|
|
|
|
|
Only build tested for I830 generation.
|
|
|
|
|
|
This seems to work now. Also fix i945 set_level_info, need to match i915
behaviour for storing mip height, as it's assumed to be the mip width
(in texels) elsewhere and the division by 4 is done later (untested).
|
|
TexelBytes is always 0 with compressed textures, thus would never match
mt->cpp. This caused constant blitting around of textures, and it fixes at
least the horrible performance of Q3 if compressed textures are enabled.
|
|
|
|
|
|
This way we have a hw context so that we can take the hardware lock.
Also, at this point, AIGLX isn't locked with the X server context as it is
at screen creation.
|
|
|
|
|
|
Don't place buffer objects on unfenced list when newly created.
Fix a buffer object wait-for-idle deadlock.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Was removed during glsl-compiler work. Still need to go back and revisit this
because of the interaction with fragment shaders...
|
|
|
|
Since the recent renderbuffer refcounting fixes it's no longer sufficient to
just remove the old renderbuffer from the framebuffer and then add the new one
because the former may decrease the reference count to 0 and delete the old
renderbuffer.
|
|
|
|
Making modifications while the editor spawned by git-commit was suspended
didn't have the intended effect.
|
|
Remove superfluous _mesa_resize_framebuffer call which is now harmful because
it causes the third renderbuffer to have width/height 0, so Mesa refuses to
render to it.
In the long term, it would be nice to remove the hack in
intel_alloc_window_storage in favour of a proper Mesa interface for flipping
between more than two colour buffers.
|