Re: [Mesa3d-dev] Rationale of gallium-resources changes?

On Sat, Mar 27, 2010 at 5:34 PM, Luca Barbieri wrote: > Having drivers capable of doing "send-to-hardware-and-forget-about-it" > on arbitrary state setting could be a nice thing instead, but > unfortunately a lot of hardware fundamentally can't do this, since for > instance: > 1. Shaders need to b

Re: [Mesa3d-dev] Rationale of gallium-resources changes?

> To me this speaks to another aspect of the gallium interface which is > a bit odd -- in particular the way several of our interfaces basically > copy their inputs into a structure and pass that back to the state > tracker.  Why are we doing that?  The state tracker already knows what > it asked u

[Mesa3d-dev] [Bug 27300] [r300g] Oolite fragment shaders are too big for r3xx

http://bugs.freedesktop.org/show_bug.cgi?id=27300 Corbin Simpson changed: What|Removed |Added Summary|r300_fs.c:209: |[r300g] Oolite fragment

[Mesa3d-dev] [Bug 24942] r300g: R300 Gallium SW TCL

http://bugs.freedesktop.org/show_bug.cgi?id=24942 Corbin Simpson changed: What|Removed |Added AssignedTo|mesa3d- |mostawesomed...@gmail.com

[Mesa3d-dev] [Bug 21997] [gallium-mesa-7.4] Add tex_transfer to pipe_screen in order to speed up glreadpixels

http://bugs.freedesktop.org/show_bug.cgi?id=21997 Corbin Simpson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

Re: [Mesa3d-dev] Rationale of gallium-resources changes?

On Wed, Mar 24, 2010 at 9:20 PM, Luca Barbieri wrote: > Thanks for providing a long insightful reply. > >>> Transfers can then be split in "texture transfers" and "buffer transfers". >>> Note that they are often inherently different, since one often uses >>> memcpy-like GPU functionality, and the

[Mesa3d-dev] [Bug 24226] libGL tries using direct mode when it should use indirect (only tries indirect if forced)

http://bugs.freedesktop.org/show_bug.cgi?id=24226 --- Comment #15 from George Sapountzis 2010-03-27 05:56:07 PST --- (In reply to comment #14) > The question is, when libGL.so is compiled with direct rendering support, how > to decide if direct rendering is viable at runtime? The connectio

[Mesa3d-dev] [Bug 17659] driver_configs never deallocated

http://bugs.freedesktop.org/show_bug.cgi?id=17659 --- Comment #1 from George Sapountzis 2010-03-27 05:49:45 PST --- (In reply to comment #0) > Created an attachment (id=19010) --> (http://bugs.freedesktop.org/attachment.cgi?id=19010) [details] > half-hearted demo patch which makes valgrind

[Mesa3d-dev] [Bug 5840] Mesa does not remove no-op state changes occuring outside rendering commands

http://bugs.freedesktop.org/show_bug.cgi?id=5840 Corbin Simpson changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|

[Mesa3d-dev] [Bug 4860] Software rasterizer polygon offset problem

http://bugs.freedesktop.org/show_bug.cgi?id=4860 Corbin Simpson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

[Mesa3d-dev] [PATCH] Fix deadlock: _mesa_HashFindFreeKeyBlock has already locked the table.

This fixes fdo bug 34502. Signed-off-by: Török Edvin --- src/mesa/main/hash.c | 19 +-- 1 files changed, 13 insertions(+), 6 deletions(-) diff --git a/src/mesa/main/hash.c b/src/mesa/main/hash.c index 9757754..e9a9748 100644 --- a/src/mesa/main/hash.c +++ b/src/mesa/main/hash.

[Mesa3d-dev] [Bug 27017] swrast not working correctly - point-wide trivial

http://bugs.freedesktop.org/show_bug.cgi?id=27017 Andrew Randrianasulu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

[Mesa3d-dev] [Bug 27018] swrast not working correctly - samples/stencil

http://bugs.freedesktop.org/show_bug.cgi?id=27018 Andrew Randrianasulu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

Re: [Mesa3d-dev] GSOC: Gallium R300 driver

On Sat, Mar 27, 2010 at 02:11:54AM +0100, Marek Olšák wrote: > > From the driver point of view, we don't have to work on the GLSL compiler > itself. The Mesa state tracker compiles GLSL to an assembler-like language > called TGSI which is then translated ([1]) to the R300 compiler ([2]) shader > r