| Age | Commit message (Collapse) | Author |
|---|
|
This patch re-emits the viewport state on framebuffer or rasterizer
change.
This seems to be necessary on nv3x, but the reason is not fully
understood.
It is quite likely that this isn't really the correct fix, but seems
to work, and makes nv3x much better.
|
|
This is a different approach to solving this problem that the patch
I previously posted, and unlike that, should not cause any problems.
Right now undefined symbols in DRI drivers will still allow the
build to succeed.
As a result, people modifying drivers they cannot test risk creating
unloadable drivers with no easy way of automatically avoiding it.
For instance, the modifications to nv50 for context transfers caused
such an issue recently.
Unfortunately, just adding -Wl,--no-undefined doesn't work, because
the DRI drivers depend on glapi symbols, but do not depend on
libGL.so.1
Adding -lGL is not the correct solution since DRI drivers are not loaded
just by libGL, but also by X and possibly by other clients.
So, this patch simply tries to build an executable linked to the DRI
driver and to libGL.
If the DRI driver contains any undefined symbols not satisfied by its
dependencies or by libGL, this will fail.
This solution does not alter the built drivers, and does not significantly
slow down the build process.
All classic DRI drivers as well as all the Gallium drivers with configure
options compiled successfully with this change.
Thanks to Xavier Chantry <chantry.xavier@gmail.com> and
Michel Daenzer <michel@daenzer.net> for helping with this.
Signed-off-by: Luca Barbieri <luca@luca-barbieri.com>
Acked-by: Brian Paul <brian.e.paul@gmail.com>
|
|
|
|
|
|
...This state's interdependent? Really? Needs moar cleanup.
|
|
May or may not be responsible for slight increases in ipers FPS.
|
|
Those paths aren't important anymore, and a debugging warning won't stop
a hardlock anyway.
|
|
This fixes a pretty big performance regression caused by commit
3475e88442c16fb2b50b903fe246b3ebe49da226.
When the user does not request a stencil buffer it's important that we
don't use a depth/stencil format (or at least make it our last choice).
If the user calls glClear(GL_DEPTH_BUFFER_BIT) when we have a combined
depth/stencil buffer, that causes us to hit the clear_with_quad() path
which can be much, much slower than calling pipe_context::clear().
Also, try to use a shallower depth format before a deeper one.
|
|
|
|
The code was half converted, resulting in texturing being totally broken.
|
|
Conflicts:
src/gallium/drivers/cell/ppu/cell_screen.c
src/mesa/state_tracker/st_cb_drawpixels.c
|
|
|
|
|
|
|
|
It requires DRM 2.1.0 (e.g. kernel 2.6.34) and is disabled on older ones.
Finally, the texture tiling implementation is now complete. Uff.
|
|
|
|
|
|
|
|
This reverts commit 97a694e2211dc804090f282d8e096c028f29579f.
|
|
This reverts commit f87a5f6499f51f651c2a9f2d4682875b22926905.
|
|
This reverts commit 5d524cce9c4fcc18ed977801d59ba7bb911020db.
|
|
This reverts commit 29ec05164838f13d9535271796a50fa213d07912.
|
|
|
|
|
|
This reverts commit 9ec29e31919e85f9230867f43841c0e74be930d3.
|
|
There's still no hint of optimization in the shaders, but
we support conditionals, loops and even integer opcodes so
it isn't that big a lie.
|
|
|
|
This partially reverts commit f87a5f6499f51f651c2a9f2d4682875b22926905.
|
|
The vertex elements and buffers might not be valid anymore.
|
|
Relocations of per-screen buffers are now emitted directly,
and include the necessary method to get changes in constbuf
addresses committed to the hw.
It should also be a bit cheaper than the way stateobjs emit
relocation markers, use a little less pushbuf space.
|
|
|
|
|
|
|
|
Not sure, but judging by softpipe, this hook was forgotten.
|
|
|
|
Okay need to revist the whole OQ stuff anyways, glean test asserts
which is never good.
I'm liking the cached bufmgr restrictions less and less, I think I'll
probably play with the fence and/or busy stuff ASAP and try and clean it up.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
This adds the cached bufmgr for vertex/index buffers on top of the kernel
manager.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Suggested by Jose on the list, probably not perfect but will let me get
past this for now, testing with a fenced bufmgr on top of this, was slower,
Also this doesn't let you do the busy early exit optimisation either from
what I can see.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
Seems like a decent idea, especially since the big barrier now is
getting the VBOs back from the VRAM boundary.
|
|
Still not happy with this, but at least things seem to work.
|
|
|
|
Slight memory savings, but more importantly also avoids a potential NULL
dereference.
|
|
If we change the tiling on a buffer we need to flush it, the old
radeon_buffer.c code had this but it crossed streams when I ported to
radeon_drm_buffer.c and I missed it. Should fix some piglit regressions.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
I've no idea about the comments that were in there, just pass
this down to the winsys.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
|
