Currently, there are several functions where static dispatch has been
disabled, but that are exported by either ATI, nVidia or both lib.
To prevent compatibility issues, it seems a good idea to export those
too at least.
What do you think?
Should we export all function exported by both nVidia
No. The libGL ABI is well defined:
http://www.opengl.org/registry/ABI/
Does the ABI forbid exporting additional functions from libGL.so?
As far as I can tell, it doesn't, and only says what is required to be
exported, and that applications shouldn't statically link to other
functions.
The
On Mon, Sep 6, 2010 at 3:57 PM, José Fonseca jfons...@vmware.com wrote:
I'd like to know if there's any objection to change the
resource_copy_region semantics to allow copies between different yet
compatible formats, where the definition of compatible formats is:
I was about to propose
How about dropping the idea that resource_copy_region must be just a
memcpy and have the driver instruct the hardware 2D blitter to write
1s in the alpha channel if supported by hw or have u_blitter do this
in the shader?
nv30/nv40 and apparently nv50 can do this in the 2D blitter, and all
This way you could copy z24s8 to r8g8b8a8, for instance.
I am not sure this makes a lot of sense. There's no guarantee the bit
layout of these is even remotely similar (and it likely won't be on any
decent hardware). I think the dx10 restriction makes sense here.
Yes, it depends on the
Yes, if x8 is interpreted as writes can write arbitrary data, reads
must return 1 (as you said), then this is not necessary in
resource_copy_region even if A8 - X8 becomes supported.
You are right that format conversions would probably be better added
as a separate function (if at all), in
When I said it won't work with decent hardware, I really meant it won't
work due to compression. Now, it's quite possible this can be disabled
on any chip, but you don't know that before hence you need to jump
through hoops to get an uncompressed version of your compressed buffer
later.
The dst blending parameter is just a factor the real dst value is multiplied
by (except for min/max). There is no way to multiply an arbitrary value by a
constant and get 1.0. But you can force 0, of course. I don't think there is
hardware which supports such flexible swizzling in the blender.
On nv30/nv40 support for patching fragment programs is already
necessary (constants must be patched in as immediates), and this can
be handled by just patching the end of the fragment program to include
a variable number of instructions to copy a temp to COLOR[x].
It's possible that there could
---
src/gallium/auxiliary/Makefile |1 +
src/gallium/auxiliary/util/u_linkage.c | 119
src/gallium/auxiliary/util/u_linkage.h | 38 ++
3 files changed, 158 insertions(+), 0 deletions(-)
create mode 100644
and r300, and
significant code for nv30/nv40, which is however already implemented.
Luca Barbieri (5):
tgsi: formalize limits on semantic indices
tgsi: add support for packing semantics in SM3 byte values
gallium/auxiliary: add semantic linkage utility code
nvfx: support proper shader linkage
---
src/gallium/include/pipe/p_shader_tokens.h | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/src/gallium/include/pipe/p_shader_tokens.h
b/src/gallium/include/pipe/p_shader_tokens.h
index baff802..5d511ba 100644
---
---
src/gallium/auxiliary/util/u_semantics.h | 123 ++
1 files changed, 123 insertions(+), 0 deletions(-)
create mode 100644 src/gallium/auxiliary/util/u_semantics.h
diff --git a/src/gallium/auxiliary/util/u_semantics.h
b/src/gallium/auxiliary/util/u_semantics.h
Still no control flow support, but basic stuff works.
---
src/gallium/drivers/nvfx/nvfx_screen.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/gallium/drivers/nvfx/nvfx_screen.c
b/src/gallium/drivers/nvfx/nvfx_screen.c
index 6742759..b935fa9 100644
---
From: Michal Krol mic...@vmware.com
Use TGSI_SEMANTIC_GENERIC for this kind of stuff.
---
src/gallium/auxiliary/tgsi/tgsi_dump.c |2 +-
src/gallium/auxiliary/tgsi/tgsi_text.c |2 +-
src/gallium/docs/source/tgsi.rst |6 --
---
src/gallium/drivers/nvfx/nvfx_fragprog.c | 146 ++--
src/gallium/drivers/nvfx/nvfx_shader.h |1 +
src/gallium/drivers/nvfx/nvfx_state.c |4 +
src/gallium/drivers/nvfx/nvfx_state.h | 15 +++
src/gallium/drivers/nvfx/nvfx_state_emit.c |2 +-
r300g: hack around issue with doom3 and 0 stride
This is most likely a bug in the mesa state tracker, but do the quick hack
for now to avoid the divide by 0.
This is not a bug: stride 0 means that the vertex attribute is
constant for all vertices.
It is not a special value either: advancing
I named it that way because it is datatype conversion functionality,
which is conceptually a lower layer than format conversion, which
operates on multi-component formats, and is also totally independent
of the existing format conversion functionality.
It is the only member of that layer because
This might depend on the target: R600+, for example, is quite
scalar-oriented anyway (modulo a lot of subtle limitations), so just
pretending that everything is scalar could work well there since
revectorizing is almost unnecessary.
Interesting, nv50 is also almost fully scalar, and based on
There was some talk about doing the query with a vertex buffer target
for is_format_supported.
After gallium-resources is merged, this should be automatically possible.
BTW, the st/mesa patch originally was from Dave Airlie and was
slightly changed by me.
Does it mean there will be format fallbacks? Because dword-unaligned but
still pretty common (i.e. GL1.1) vertex formats aren't supported by r300,
most often we hit R16G16B16. What will happen when is_format_supported says
NO to such a format? I hope it won't share the fate of PIPE_CAP_SM3,
If you mean that r300 doesn't support R16G16B16, I suppose you can
just use R16G16B16A16 and ignore the extra fetched w element (the
vertex buffer stride will make this work properly).
I've tried to do it this way, it locks up (unless I am missing something).
Shouldn't there be official ATI
Way back I actually looked into LLVM for R300. I was totally
unconvinced by their vector support back then, but that may well have
changed. In particular, I'm curious about how LLVM deals with
writemasks. Writing to only a select subsets of components of a vector
is something I've seen in a
They are not passing for me with current master and a 32-bit system:
Here are the failures:
Testing util_format_dxt1_rgb_pack_8unorm ...
FAILED: f2 d7 90 20 ae 2c 6f 97 obtained
f2 d7 b0 20 ae 2c 6f 97 expected
Testing util_format_dxt5_rgba_pack_8unorm ...
FAILED: f7 10 c5 0c 9a 73 b4
For instance, the DXT1 test is wrong.
The red values used are:
33
93
153
214
99 - 33 = 60
153 - 93 = 60
214 - 153 = 61
213 should be used instead (i.e. 0xd5 instead 0xd6)
--
Download Intel#174; Parallel Studio Eval
Try
Collect the maximum error for fetch/unpack tests, and ratio of flipped
to total bits for pack tests.
Add lenient thresholds for S3TC tests.
---
progs/gallium/unit/u_format_test.c | 163 +++-
1 files changed, 86 insertions(+), 77 deletions(-)
diff --git
This is somewhat nice, but without using a real compiler, the result
will still be just a toy, unless you employ hundreds of compiler
experts working full time on the project.
For instance, Wikipedia lists the following loop optimizations:
# loop interchange : These optimizations exchange inner
As a further example that just came to mind, nv40 (GeForce 6-7 and PS3
RSX) supports control flow in fragment shaders, but does not
apparently support the continue keyword (since NV_fragment_program2,
which maps almost directly to the hardware, does not have it either).
I implemented TGSI control
By the way, if you want a simple, limited and temporary, but very
effective, way to optimize shaders, here it is:
1. Trivially convert TGSI to GLSL
2. Feed the GLSL to the nVidia Cg compiler, telling it to produce
optimized output in ARB_fragment_program format
3. Ask the Mesa frontend/state
I don't agree with this. Making the format description table mutable when the
only formats that are potentially unsupported due to patent issues are s3tc
variants makes no sense. S3TC formats *are* special. There is nothing to
generalize here.
Yes, I don't like this very much either.
The
I agree with you that doing these kinds of optimizations is a difficult
task, but I am trying to focus my proposal on emulating branches and
loops for older hardware that don't have branching instructions rather
than performing global optimizations on the TGSI code. I don't think
most of the
Gallium. Obviously a code-generator that can handle control-flow (to be honest
I'm really not sure why you want to restrict it to something without control-
flow in the first place).
The no-control-flow was just for the first step, with a second step
supporting everything.
Having said that
So basically the r300 optimization work looks doomed from the
beginning to be eventually obsoleted.
Please consider there are hw-specific optimizations in place which I think
no other compiler framework provides, and I believe this SSA thing will do
Sure, but it seemed to me that all the
How about merging gallium-buffer-usage-cleanup as well, which is based
on gallium-resources?
Unless, it changed recently, the gallium-resources branch left a mix
of old PIPE_BUFFER_USAGE_* and new PIPE_TRANSFER_* flags.
It would nice to convert drivers having both branches, so that it is done
FWIW, I don't see any new s3tc formats. rgtc will not be handled by s3tc
library since it isn't patent encumbered. util_format_is_s3tc will not
include rgtc formats.
(Though I guess that external decoding per-pixel is really rather lame,
should do it per-block...)
Yes the other formats (rgtc
So far, there are no dependencies on Gallium in core Mesa.
We've talked about refactoring some of the Gallium code into a separate
module that'd be sharable between Gallium and Mesa. The format code would
probably fit into that.
Can't we just unconditionally pull gallium/auxiliary in Mesa?
What are you seeing a regression on?
texcompress and texcompsub seemed to work for me: I'll try to test
something else and recheck the code.
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for
80214ef6265d406496dc4fd3c76d8ac782cd012b
Author: Luca Barbieri l...@luca-barbieri.com
Date: Sat Apr 3 01:55:27 2010 +0200
gallium/util: fix inverted if is_nop logic in s3tc
diff --git a/src/gallium/auxiliary/util/u_format_s3tc.c
b/src/gallium/auxiliary/util/u_format_s3tc.c
index d48551f..7808210 100644
--- a/src/gallium
One more thing: I'm maintaining the u_format* modules. I'm not speaking the
just in the long term, but in the sense I'm actually working on this as we
speak. Please do not make this kind of deep reaching changes to the u_format
stuff in master without clearing them first with me.
Yes
The s3tc-teximage test seems fixed by the two line change I put in
gallium-util-format-is-supported.
s3tc-texsubimage prints:
Mesa: User error: GL_INVALID_VALUE in glTexSubImage2D(xoffset+width)
Probe at (285,12)
Expected: 1.00 0.00 0.00
Observed: 0.00 0.00 0.00
which
Once MS changes interfaces, then there's _no advantage_ to using DX10
internally, regardless of what WINE does, and one might as well use
OpenGL. Wine doesn't change that.
[resent to ML, inadvertently replied only to Miles]
Note that my proposal was not to use DirectX 10 internally, but
This constructor scheme is not working for me. I think that's because
there isn't any symbol here that's used elsewhere, hence the linker is
not linking this file.
I replaced the system with a different mechanism.
It should now work correctly, but only GCC and MSVC are supported, and
the
The half float conversion code initially used a global C++ constructor
to initialize the tables.
That fails to work since ld does not get the symbol from the shared
library, so I changed to use register a global constructor from C,
using GCC- or MSVC-specific code.
This is not necessarily the
OK.
I'd like to add that u_atomic.h already requires either GCC, MSVC or
Solaris, and GCC and MSVC are already supported by this system.
Thus we do indeed now have a simple way to do global constructors,
that only removes support for non-GCC Solaris until someone figures
out how to do that.
And
Are you sure about this?
I've tried doing it, and it turns out that basically every Gallium
module needs this initialized.
For instance:
st/mesa due to glReadPixels
vg/mesa due to vgReadPixels
st/python due to mesa sampling
several programs in rbug to dump textures to disk
softpipe due to
WINE can deal with that. The real showstopper is that WINE has to also
work on MacOS X and Linux + NVIDIA blob, where Gallium is unavailable.
We could actually consider making a Gallium driver that uses OpenGL to
do rendering.
If the app uses DirectX 10, this may not significantly degrade
[sent to ML too]
Michal,
I noticed you made some commits related to half float support in Gallium.
I had already done this work and implemented a fast conversion
algorithm capable of handling all cases based on a paper cited in the
commit, but hadn't gotten around to proposing it yet.
I created
Should be fixed now.
BTW, if it is still not compiling due to the __sync* issues, try
adding CFLAGS=-march=v9 to the build: it should fix that.
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for
Another idea was to convert TGSI to a SSA form. That would make unrolling
branches much easier as the Phi function would basically become a linear
interpolation, loops and subroutines with conditional return statements
might be trickier. The r300 compiler already uses SSA for its optimization
There are several deep challenges in making TGSI - LLVM IR translation
lossless -- I'm sure we'll get around to overcome them -- but I don't
think that using LLVM is a requirement for this module. Having a shared
IR for simple TGSI optimization module would go a long way by itself.
What are
DDX/DDY could cause miscompilation, but I think that only happens if
LLVM clones or causes some paths to net execute them.
Someone proposed some time ago on llvmdev to add a flag to tell llvm
to never duplicate an intrinsic, not sure if that went through (iirc,
it was for a barrier instruction
On Tue, 2010-03-30 at 09:52 -0700, Luca Barbieri wrote:
There are several deep challenges in making TGSI - LLVM IR translation
lossless -- I'm sure we'll get around to overcome them -- but I don't
think that using LLVM is a requirement for this module. Having a shared
IR for simple TGSI
An interesting option could be to provide a DirectX 10 implementation
using TGSI text as the shader interface, which should be much easier
than one would think at first.
DirectX 10 + TGSI text would provide a very thin binary compatible
layer over Gallium, unlike all existing state trackers.
It
Interestingly, the post-trial judge opinion at
http://wi.findacase.com/research/wfrmDocViewer.aspx/xq/fac.%5CFDCT%5CWWI%5C2008%5C20080801_734.WWI.htm/qx
contains the following text:
Plaintiff’s expert, Dr. Stevenson, testified that the ‘327 patent is
directed to “a special
purpose hardware
If the application provides s3tc-encoded data through
glCompressedTexImage (usually loaded from a pre-compressed texture
stored on disk), Mesa will pass it unaltered to the graphics card (as
long as the driver/card supports DXT* format ids) and will not need to
use any encoding or decoding
On Sun, Mar 28, 2010 at 7:36 PM, Chris Ball c...@laptop.org wrote:
Hi,
http://tinderbox.x.org/builds/2010-03-25-0018/logs/libGL/#build
swrastg_dri.so.tmp: undefined reference to `__sync_sub_and_fetch_4'
swrastg_dri.so.tmp: undefined reference to `__sync_add_and_fetch_4'
This
I posted something similar some time ago, that however could use
hardware accelerated drivers with DRI2 or KMS, provided a substantial
set of helpers and offered a complement of 3 demos.
My solution to window-system issues was to simply have the application
provide a draw callback to the
I just noticed a potentially interesting thing.
nVidia publishes under the MIT license a software suite called nVidia
texture tools.
This includes a library called nvtt that provides DXT* compression,
plus a library called nvimage that provides decompression.
It looks like the libraries can be
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 us to
Are you sure that swrastg and/or any Gallium driver actually load
correctly and work on sparc64?
This seems to indicate that they use __sync_add_and_fetch_4 assuming
it is a GCC builtin, but GCC does not implement it as a builtin on
sparc64 and neither libgcc nor libc have an implementation of
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 other often uses 2D blitter or
3D engine functionality (and needs to
We have a visual haveStencilBuffer == 1 but stencilBits == 0 (and no
stencil renderbuffer), which I suppose shouldn't be happening.
visualid and fbconfigid are also 0.
Here is the full structure:
$1 = {next = 0x0, rgbMode = 1 '\001', floatMode = 0 '\000',
colorIndexMode = 0 '\000',
The problem seems to be in st_manager.c:
if (visual-depth_stencil_format != PIPE_FORMAT_NONE) {
mode-haveDepthBuffer = GL_TRUE;
mode-haveStencilBuffer = GL_TRUE;
mode-depthBits =
util_format_get_component_bits(visual-depth_stencil_format,
The issue should be hopefully completely fixed by
7e246e6aa63979d53731a591f4caee3651c1d96b.
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and
On Tue, Mar 23, 2010 at 10:45 PM, Sedat Dilek
sedat.di...@googlemail.com wrote:
The issue should be hopefully completely fixed by
7e246e6aa63979d53731a591f4caee3651c1d96b.
Unfortunately, build breaks here.
Not sure which of the last changes really breaks it.
Hopefully fixed that too now.
According to the logs, that build was not based on that commit, which
instead actually fixes that issue.
http://tinderbox.x.org/builds/2010-03-23-0040/ was actually the first
tinderbox build using that, and it went past that issue to fail on
xeglthreads problem, which is unrelated.
Thanks anyway
It may seem e.g. like the DRM interface is the worst because of rather large
threads caused by certain kernel developer's problems, but that doesn't mean
problems wouldn't be created by splitting other areas.
This would probably be best solved by merging libdrm into the Linux kernel tree.
How about applying this?
It should prevent introducing regressions similar to ones that
happened in the past, with very little downside.
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for
Can we just put this program in the demos? Or at least just make it a
separate target (make test-link)? It seems excessive to make this part
of the default build path.
The whole purpose is to run this as part of the standard build, so
that the build fails if any driver is unloadable, (i.e. a
For developers that makes a lot of sense, but I've never seen any
other projects impose this type of thing on regular users.
Why do you see it as an onerous imposition?
It just tries to compile a program linked with a couple of libraries
(the DRI driver, plus libGL) and makes the build fail if
---
src/gallium/drivers/nv40/nv40_transfer.c | 181 --
1 files changed, 0 insertions(+), 181 deletions(-)
delete mode 100644 src/gallium/drivers/nv40/nv40_transfer.c
diff --git a/src/gallium/drivers/nv40/nv40_transfer.c
b/src/gallium/drivers/nv40/nv40_transfer.c
Adding both -Wl,--no-undefined and -lGL (in
src/gallium/winsys/drm/Makefile.template) seems to work for me.
The driver loader is already loading libGL.so.1 with RTLD_NOW |
RTLD_GLOBAL, so I think that the DRI driver depending on libGL.so.1
shouldn't introduce any issue.
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
Perhaps try running make clean and make if you haven't already?
And perhaps make sure that the installed libGL.so and DRI drivers are
build from the same codebase.
The changes in my branch definitely shouldn't affect this.
I wanted to merge Lucsa' branch in to my copy of Mesa master to test it
But for any such technique, the mesa state tracker will need to figure
out what memory is being referred to by those non-VBO vertex buffers
and to do that requires knowing the index min/max values.
Isn't the min/max value only required to compute a sensible value for
the maximum user buffer
Currently the nv30 and nv40 Gallium drivers are very similar, and
contain about 5000 lines of essentially duplicate code.
I prepared a patchset (which can be found at
http://repo.or.cz/w/mesa/mesa-lb.git/shortlog/refs/heads/unification+fixes)
which gradually unifies the drivers, one file per the
What if you have a non-integer min LOD?
While the integer part may belong to the sampler view, the fractional
part really seems to be a sampler property.
Requiring min_lod 1.0 also doesn't seem to make much sense, so
shouldn't it be kept as it is now?
Same thing for last_level / max_lod.
Isn't it possible to compute the maximum legal index by just taking
the minimum of:
(vb-buffer-size - vb-buffer_offset - ve-src_offset) / vb-stride
over all vertex buffers/elements?
Isn't the kernel checker doing something like this?
Actually, why is the state tracker doing the min/max computation at all?
If the driver does the index lookup itself, as opposed to using an
hardware index buffer, (e.g. the nouveau drivers do this in some
cases) this is unnecessary and slow.
Would completely removing the call to
I've looked into the issue, and found a workaround by looking at what
st_renderbuffer_alloc_storage (which is called to create the depth
buffer with ST_SURFACE_DEPTH != BUFFER_DEPTH) does.
Adding:
if(ctx) ctx-NewState |= _NEW_BUFFERS;
at the end of st_set_framebuffer_surface seems to solve the
Solves the Warsow issue and seems to work.
Thanks!
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel
Shouldn't
_mesa_add_renderbuffer(stfb-Base, BUFFER_FRONT_LEFT, rb);
be
_mesa_add_renderbuffer(stfb-Base, surfIndex, rb);
instead, since you seem to make the on-demand creation mechanism
generic and no longer limited to the front buffer?
In mesa_7_7_branch, 52d83efdbc4735d721e6fc9b44f29bdd432d4d73 reverts
commit 9d17ad2891b58de9e33e943ff918a678c6a3c2bd.
How about cherry-picking that commit into master, until a fix for the
bugs the revert commit introduces are found?
The reverted commit currently breaks the Warsow main menu for
We can do this optimisation with busy as well. As long as you add
things to the busy list at the end, and stop testing after the first
busy call. At least for a single linear GPU context, which is all
I expect this code will ever be handling.
Wouldn't this just end up reinventing the fenced
I think you are supposed to do this using the fenced bufmgr over
cached along with a (ideally userspace) fencing mechanism.
If you can implement pb_busy, you should be able to implement
fence_signalled in exactly the same way (making the fence handle a
pointer to buffers should work for this
For static analysis with Coverity Prevent, the added assert will clear a
defect report and/or allow it to continue parsing to the next possible defect.
Are these being checked manually and determined to be false positives?
If not, then it would be beneficial to not shut up static analysis,
Just noticed that has already been fixed in
5f40a7aed12500fd6792e2453f49c3b5c54d with an if(attrib_list).
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
PIPE_FORMAT_X8B8G8R8_UNORM is being used by mesa. PIPE_FORMAT_R8G8B8X8_UNORM
doesn't exist hence it appears to be unnecessary. So it doesn't make sense to
rename.
How about D3DFMT_X8B8G8R8? That should map to PIPE_FORMAT_R8G8B8X8_UNORM.
BTW, we are also missing D3DFMT_X4R4G4B4,
BTW, i915 is also limited to 0-7 generic indices, and thus doesn't
work with GLSL at all right now.
This should be relatively easy to fix since it should be enough to
store the generic indices in the texCoords arrays, and then pass
them to draw_find_shader_output.
I've been looking at shader semantics some more, and I'm a bit
surprised by how the svga driver works.
It seems that an obvious implementation of a DirectX 9 state tracker
just won't work with the svga driver.
In SM3, vertex/fragment semantics can be arbitrary (independent of
hardware resources),
I don't think anybody has tried hooking it up - so far the primary
purpose of the svga gallium driver has been GL support, but thinking
about it you're probably right.
I'm a bit confused about this: I was under the impression that VMware
Tools for Windows used your DirectX state tracker and a
The difference between an easier and harder life for (some) drivers is
whether the limit is tied to hardware interpolators or not.
Once we decide to not tie it, whether the limit is 128 or 256 is of
course quite inconsequential.
Allowing arbitrary 32-bit values would however require use of binary
On Tue, Mar 2, 2010 at 10:00 PM, Corbin Simpson
mostawesomed...@gmail.com wrote:
FYI r300 only supports 24 interpolators: 16 linear and 8 perspective.
(IIRC; not in front of the docs right now.) r600 supports 256 fully
configurable interpolators.
Yes, but if you raised ATTR_GENERIC_COUNT, the
Shouldn't
PIPE_FORMAT_X8B8G8R8_UNORM= 68,
be instead R8G8B8X8_UNORM, which is currently missing, for consistency with:
PIPE_FORMAT_R8G8B8X8_SNORM= 81,
with X8B8G8R8_UNORM perhaps put at the end next to PIPE_FORMAT_A8B8G8R8_UNORM?
Falling back to CPU rendering, while respecting the OpenGL spec, is
likely going to be unusably slow in most cases and thus not really
better for real usage than just not rendering.
I think the only way to have an usable fallback mechanism is to do
fallbacks with the GPU, by automatically
I see that PK2US and friends are being removed.
These would be necessary to implement NV_fragment_program_option,
NV_fragment_program2 and NV_gpu_program4.
Currently the no drivers (including Nouveau) support them, but since
we already have some support in Mesa (even parsers for the nVidia
The cache manager stores buffers with a reference count that dropped to 0.
pipe_reference asserts in this case on debug builds,
so use pipe_reference_init instead.
---
src/gallium/auxiliary/pipebuffer/pb_bufmgr_cache.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
A return of 0 means the fence is signalled.
---
.../auxiliary/pipebuffer/pb_buffer_fenced.c|2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
b/src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
index
Good catch of the fence_signalled
negated logic.
This was actually mentioned on IRC by Maarten Maathuis (who was
working on adding pipebuffer support to the nv50 driver).
Thanks to him :)
--
Download Intel#174;
+ if (flags PIPE_BUFFER_USAGE_UNSYNCHRONIZED) {
This should be:
if (!(flags PIPE_BUFFER_USAGE_UNSYNCHRONIZED)) {
Sorry for this.
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself.
1 - 100 of 217 matches
Mail list logo
