On Wed, Jan 13, 2010 at 3:55 AM, Chia-I Wu wrote:
> On Wed, Jan 13, 2010 at 2:52 AM, Luca Barbieri wrote:
>> Doesn't this make two DRI2GetBuffers protocol calls, in case of a resize?
> I expect resizing happens rarely.
It likely happens every frame while the user is resizin
>> validate_and_get_current_sequence_number(), and the results reused in
>> update_buffers().
> This works too. It assumes fast texture creation (as they are always asked
> for), which is true with your DRI2 texture cache patch.
It's even better, they would only asked for is the surface is updated
On Thu, Jan 14, 2010 at 9:27 AM, Chia-I Wu wrote:
> On Thu, Jan 14, 2010 at 4:08 PM, Luca Barbieri wrote:
>>>> validate_and_get_current_sequence_number(), and the results reused in
>>>> update_buffers().
>>> This works too. It assumes fast texture creati
What are the advantages of the new DRI2 event over the existing ConfigureNotify?
Couldn't that be used as a fallback on older servers?
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's bes
How about just having GLX open another connection to the X server and
use that to receive ConfigureNotify?
Since we are using direct rendering, we must be on the same machine,
so it's just a unix/TCP loopback connection and should always work.
Xlib stores the display name in _XDisplay.display_name
Using SIGIO would be a problem in a library.
However, the kernel can be told to send an arbitrary signal (see
F_SETSIG) and glibc can allocate realtime signals with
__libc_allocate_rtsig() (pthread uses this for internal signals).
---
__glXSetCurrentContextNull currently does not set the GL context to null
in the direct rendering case.
This can result in a segfault trying to flush an invalid old context
in glXMakeCurrent.
This fixes a crash starting the Unigine demos (they still don't work due
to missing extensions though).
--
) GLSL work on NV30/NV40 and improves the
chances of complex programs working on other cards.
Signed-off-by: Luca Barbieri
---
src/mesa/shader/slang/slang_link.c | 62 ++-
1 files changed, 46 insertions(+), 16 deletions(-)
diff --git a/src/mesa/shader/slang
> How do you make sure events are ordered correctly? Say a window is
> resized and the client receives the ConfigureNotify event before us, and
> it reacts drawing on the newly exposed areas: we aren't guaranteed to
> have received our event yet, so it might end up rendered in the old
> buffers.
OK
Sauerbraten triggers this assert.
---
src/mesa/state_tracker/st_atom_shader.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_shader.c
b/src/mesa/state_tracker/st_atom_shader.c
index 176f3ea..fce533a 100644
--- a/src/mesa/state_tracker/st_a
---
src/gallium/drivers/nv40/nv40_fragprog.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/gallium/drivers/nv40/nv40_fragprog.c
b/src/gallium/drivers/nv40/nv40_fragprog.c
index 1237066..209d211 100644
--- a/src/gallium/drivers/nv40/nv40_fragprog.c
+++ b/src/galliu
> I think this is not necessary and fixing the rasterizer setup in the driver
> would by better than fixing the state tracker.
>
> In r300g, we dynamically allocate rasterizer units based on vertex shader
> outputs. If the vertex shader uses slots 1, 5, 20, 100, the driver maps
> them to units
Cool!
I'll add nv40 support (and Gallium support if it's still missing).
nv50 also supports this in hardware, and maybe nv30 too.
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best an
So, basically, you allocate the rasterizer units according to the
vertex shader, and when the fragment shader comes up, you say "write
rasterizer output 4 to fragment input 100"?
The current nouveau drivers can't do this.
There are "routing" registers in hardware, but I think the nVidia
propri
This requires the arb_half_float_vertex Mesa branch, plus some unreleased
gallium support work by Dave Airlie.
You may need to fix an assertion in st_pipe_vertex_format too.
---
src/gallium/drivers/nv40/nv40_vbo.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --gi
Breakpoint 3, _mesa_ProgramStringARB (target=34820, format=34933,
len=70, string=0x85922ba) at shader/arbprogram.c:434
434GET_CURRENT_CONTEXT(ctx);
$31 = 0x85922ba "!!ARBfp1.0\n\nOPTION
ARB_precision_hint_fastest;\n\n\n\nEND\n"
Not sure why Sauerbraten does this, but it doe
> But the assertion should be changed to "num instructions > 0" and not
> removed. I'll fix that.
OK.
Programs without END should be rejected by the parser anyway though.
--
Throughout its 18-year history, RSA Conference
> If you get this patch in, then you'll still have to fight with every
> other state tracker that doesn't prettify their TGSI. It would be a
> much better approach to attempt to RE the routing tables.
I don't think there any users of the Gallium interface that need more
than 8 vertex outputs/fragm
> Either way, I anticipate having to build a function that, given a
> pipe_vertex_element and pipe_vertex_buffer, and a list of acceptable
> pipe_formats, internally magically modifies things inside so that all
> resulting VBOs are safe for HW.
As I mentioned on IRC, it may be possible to avoid th
What are the Gallium semantics for nested buffer maps and unmaps?
The current situation seems the following:
- Nouveau doesn't support nested mapping. It fully supports them with
a patch to libdrm I posted.
- r300 fully supports nested mapping
- VMware supports nested mapping, but only the outermo
The XImage backend keeps a transfer permanently and map/unmaps to do
modifications.
However, Gallium transfers can be implemented by making and keeping a
copy of the surface, flushing it back on transfer destruction.
Thus, it should be fixed to create and destroy a transfer every time
it maps the
Investigating a vertical flipping problem in Doom 3, I discovered that
fragment shader wpos handling is incorrect in the nv40 driver.
The issue is that nv40 provides a "position" register with OpenGL
semantics, so if TGSI_SEMANTIC_POSITION is directly wired to it (as
the nv40 driver incorrectly do
My commit eea6a7639f767b1d30b6ef1f91a9c49e3f3b78f0 does a memcpy of height
lines, but that's wrong because the texture has a block layout and we
must thus use the number of vertical blocks instead of the height.
---
src/mesa/state_tracker/st_cb_texture.c |6 --
1 files changed, 4 insertion
> Since nv40 pipe doesn't invert anything itself, it seems it also renders
> Y_0_TOP (coordinates after vport transform) but FragCoord is the other
> way ? That's odd, makes me think there should be a switch, but then ...
> maybe they just built it the OpenGL way back then.
> (do you have GL_ARB_fr
> On the other hand, part of the reason this is acceptable in r300 is
> that we do SSA and DCE during shader compile, so a double inversion
> doesn't hurt us as much. :3
nv30/nv40 mostly do 1:1 mapping to the hardware, and it would be great
to keep it that way as much as possible.
What if we add
BTW, the ximage backend may be useful to do hardware accelerated
rendering on a local DRM card (with an hardware Gallium driver), but
display the result over a remote X11 connection.
This could be useful for instance to do development on multiple
Gallium drivers for different cards while working o
I'll send a patch series implementing
GL_ARB_fragment_coord_conventions once I finish it, which will fix the
issue detailed in this thread and also add that OpenGL 3.1
functionality.
--
Throughout its 18-year history, RSA
> I think I'd prefer to avoid pushing new requirements into drivers -
> intel, vmware-svga, etc, to implement something which is handled pretty
> easily in the state tracker.
Yes, this will require all drivers to be changed.
However, this is only relatively hard for drivers that support DirectX
10
> Indeed, you won't really notice this until you start looking at
> conformance or particularly demanding applications.
Indeed, softpipe is currently broken as the fractionary part of
fragment.position is 0.
Forcing drivers to implement this will force drivers writers to think
about it and thus ge
Fixes link/runtime errors for missing glXGetProcAddressARB.
---
src/mesa/drivers/x11/glxapi.c | 24
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/src/mesa/drivers/x11/glxapi.c b/src/mesa/drivers/x11/glxapi.c
index a17c2c3..8a43c78 100644
--- a/src/mesa
---
progs/fp/position-frc-integer.txt |7 +++
progs/fp/position-frc.txt |6 ++
progs/fp/position-upper-left.txt |7 +++
progs/fp/position.txt |2 ++
4 files changed, 22 insertions(+), 0 deletions(-)
create mode 100644 progs/fp/position-frc-integer.
---
src/mesa/main/extensions.c|1 +
src/mesa/main/mtypes.h|3 +++
src/mesa/shader/arbprogparse.c|2 ++
src/mesa/shader/program_parse_extra.c | 12
src/mesa/shader/program_parser.h |2 ++
5 files changed, 20 insertions(+), 0 de
This is totally untested and only a proof of concept.
In particular, it may be necessary to add code to re-emit shader
constants on framebuffer height change.
---
src/gallium/drivers/r300/r300_emit.c |9 +
src/gallium/drivers/r300/r300_fs.c |2 ++
src/gallium/drivers
The state tracker will use the TGSI convention properties if the hardware
exposes the appropriate capability, and otherwise adjust WPOS itself.
Thus, this patch will work on unmodified drivers, and not require any
changes
However, this should only be a temporary solution, and all drivers should
e
The pixel center condition of softpipe was previously, incorrectly,
INTEGER.
This patch supports the new properties and also fixes this bug.
---
src/gallium/auxiliary/draw/draw_vertex.h|7 +++-
src/gallium/drivers/softpipe/sp_screen.c|3 ++
src/gallium/drivers/softpipe/sp_
These drivers were broken and this fixes them.
---
src/gallium/drivers/nv04/nv04_screen.c |3 +++
src/gallium/drivers/nv10/nv10_screen.c |3 +++
src/gallium/drivers/nv20/nv20_screen.c |3 +++
src/gallium/drivers/nv30/nv30_screen.c |3 +++
src/gallium/drivers/nv40/nv40_screen.c |
This adds two TGSI fragment program properties that indicate the
fragment coord conventions.
The properties behave as described in the extension spec for
GL_ARB_fragment_coord_conventions, but the default origin in
upper left instead of lower left as in OpenGL.
The syntax is:
PROPERTY FS_COORD_OR
> For nv, could this be exposed as a hardware capability which the
> state-tracker could take advantage of, and if not present fall back to
> the current shader modification in the state-tracker?
I did exactly this in the patchset I sent.
The driver can support any set of fragment coord conventions
On Thu, Jan 21, 2010 at 9:05 AM, Chia-I Wu wrote:
> On Thu, Jan 21, 2010 at 2:36 PM, Luca Barbieri wrote:
>> @@ -1132,7 +1132,7 @@ glXReleaseTexImageEXT(Display *dpy, GLXDrawable
>> drawa
> The GLX dispatch layer in src/mesa/drivers/x11/ should be removed. It
> hasn't been used in years. I removed it from the stripped-down GLX in
> src/gallium/state_trackers/glx/xlib/. That could be followed as an exmaple.
How about doing the opposite, and using it in the DRI GLX libGL too?
I us
>> These are an even more a temporary measure until drivers are fixed.
>
> What will the final set of cap bits look like?
>
> I'm hesitant to commit code with the temporary "NO_CAPS".
The plan would be to have all Gallium drivers internally support all
conventions and then remove all the caps intr
On Thu, Jan 21, 2010 at 6:34 PM, Corbin Simpson
wrote:
> Maybe it's just me, since I actually wrote the docs, but does anybody
> else read them?
>
> From cso/rasterizer.html (viewable at e.g.
> http://people.freedesktop.org/~csimpson/gallium-docs/cso/rasterizer.html
> ):
>
> gl_rasterization_rules
Changes:
- Updated formatting
The state tracker will use the TGSI convention properties if the hardware
exposes the appropriate capability, and otherwise adjust WPOS itself.
Thus, this patch will work on unmodified drivers, and not require any
changes.
However, this should only be a temporary so
Changes:
- Now takes the fragment convention directly from the fragment shader
The pixel center condition of softpipe was previously, incorrectly,
INTEGER.
This patch supports the new properties and also fixes this bug.
---
src/gallium/drivers/softpipe/sp_screen.c |3 +++
src/gallium/drive
How about this?
I'm using it locally for nv40 immediate mode vertex emission.
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -236,6 +236,8 @@ enum pipe_transfer_usage {
#define PIPE_BUFFER_USAGE_VERTEX(1 << 5)
#define PIPE_BUFFER_USAGE_INDEX (1 <
How about this?
I'm using it locally for nv40 immediate mode vertex emission.
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -236,6 +236,8 @@ enum pipe_transfer_usage {
#define PIPE_BUFFER_USAGE_VERTEX(1 << 5)
#define PIPE_BUFFER_USAGE_INDEX (1 <
> Signed-off-by: Brian Paul
Please push this as well.
Thanks.
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
att
Changes in v3:
- Use positive caps instead of negative ones
Changes in v2:
- Updated formatting
The state tracker will use the TGSI convention properties if the hardware
exposes the appropriate capability, and otherwise adjust WPOS itself.
This will also fix some drivers that were previously bro
Changes in v2:
- Caps are added in a separate, subsequent patch
This adds two TGSI fragment program properties that indicate the
fragment coord conventions.
The properties behave as described in the extension spec for
GL_ARB_fragment_coord_conventions, but the default origin in
upper left instead
Changes in v2:
- Split from properties patch
- Use positive caps instead of negative caps
This adds 4 caps to indicate support of each of the fragment coord
conventions.
All drivers are also modifed to add the appropriate caps (3 lines each).
Some drivers were incorrectly using non-Gallium-defau
Changes in v3:
- Use positive caps instead of negative caps
Changes in v2:
- Now takes the fragment convention directly from the fragment shader
Adds internal support for all fragment coord conventions to softpipe.
This patch is not required for use with the current state trackers, but it
allows
On Tue, Jan 26, 2010 at 12:11 PM, Keith Whitwell wrote:
> Luca,
>
> I would have expected fragment coord conventions to be device state, not
> a part of the shader.
>
> It seems like these new flags are really peers (or replacements?) of the
> gl_rasterization_rules flag in pipe_rasterizer_state,
> First adds a new screen interface for is_vertex_format_supported and also
> we seems to have some GPUs with a single R16 and some with R16X16 so allow
> or this.
Are you sure this is necessary?
Vertex shader formats have an explicitly specified stride, and so
padding does not matter for them.
> Didn't Keith had objections on this, on another thread? Luca re-sent the
> patch but I don't see the remark being addressed.
>
> Forwarded Message
>> From: Keith Whitwell
>> To: Luca Barbieri
>> Cc: mesa3d-dev@lists.sourceforge.net
>
On Wed, Jan 27, 2010 at 5:49 PM, Brian Paul wrote:
> Luca Barbieri wrote:
>>
>> Changes in v3:
>> - Use positive caps instead of negative ones
>>
>> Changes in v2:
>> - Updated formatting
>>
>> The state tracker will use the TGSI convention pr
> Hmmm, I'd really rather not special-case the extension code for this one
> thing.
Isn't it possible to accomplish this by commenting out the following
line from extensions.c:
+ { OFF, "GL_ARB_fragment_coord_conventions",
F(ARB_fragment_coord_conventions) },
Then swrast and Gallium can set ARB_fr
Changes in v4;
- Implemented Brian Paul's style suggestions
Changes in v3:
- Use positive caps instead of negative ones
Changes in v2:
- Updated formatting
The state tracker will use the TGSI convention properties if the hardware
exposes the appropriate capability, and otherwise adjust WPOS itse
Exposing it was incorrect, as the GLSL part of the extension is
missing.
We still keep the ARB_fragment_coord_conventions field, so that the
ARBfp parser can know whether to accept or reject the keywords.
---
src/mesa/main/extensions.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
Changes in v3:
- Renumber caps to accomodate caps to add to master in the meantime
- Document caps
- Add unsupported caps to *_screen.c too
Changes in v2:
- Split for properties patch
- Use positive caps instead of negative caps
This adds 4 caps to indicate support of each of the fragment coord
c
Changes in v3:
- Documented the new properties
- Added comments for property values
- Rebased to current master
Changes in v2:
- Caps are added in a separate, subsequent patch
This adds two TGSI fragment program properties that indicate the
fragment coord conventions.
The properties behave as de
Changes in v4:
- Rebase and modify for changes in previous patches
Changes in v3:
- Use positive caps instead of negative caps
Changes in v2:
- Now takes the fragment convention directly from the fragment shader
Adds internal support for all fragment coord conventions to softpipe.
This patch is
Patchset resent addressing comments, adding unsupported caps to
*_screen too, and documenting the added caps and properties.
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterpri
Based on work by Dave Airlie.
Adds the 4 vertex formats for half float vertices.
This differs from Dave Airlie's patch in that it does not add padded
formats, but rather uses the convention already used for vertex
formats.
This allows to simplify the patches and is consistent with the
existing c
Based on work by Dave Airlie.
Changes by me:
1. Fix assertion in st
2. Change to use unpadded Gallium formats
---
src/mesa/state_tracker/st_draw.c | 11 ++-
src/mesa/state_tracker/st_extensions.c |1 +
2 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/src/mesa/st
I'd like to have some more definitive review comments on this patch
(sending to Brian and Keith for this).
Right now GLSL is the *only* Gallium user that does not use sequential
indexes starting from 0 for vertex shader outputs and fragment shader
inputs.
This causes problems for some drivers such
from this webmail client is a total pain... Let me look
> figure out an alternative.
>
> Keith
> ____
> From: Luca Barbieri [l...@luca-barbieri.com]
> Sent: Thursday, January 28, 2010 10:18 PM
> To: Brian Paul
> Cc: Luca Barbieri; mesa3d-de
> FWIW, I think DX10 required or at least encouraged semantic mapping
> support in hardware. R6xx+ radeons support this and r3xx-r5xx
> hardware do to a lesser degree. You can use arbitrary, driver
> specific ids and the hardware will match up inputs and outputs based
> on those ids.
Can you pro
> Luca,
>
> Let me make sure I understand the problem here.
>
> Are you specifically concerned about the GENERIC[x] semantic
> labels/indexes that are attached to VS outputs and FS inputs?
Yes.
> This is as intended. The semantic indexes are used to match up
> inputs/outputs logically but they sh
As a concrete example, the current nv40 code does this during fragment
program translation.
case TGSI_SEMANTIC_GENERIC:
if (fdec->Semantic.Index <= 7) {
hw = NV40_FP_OP_INPUT_SRC_TC(fdec->Semantic.
I just read the extension, and it seems to be that it clearly
indicates that routing is *not* used by OpenGL.
In particular, varyings with the same name are not linked together,
and instead the builtin varyings must be used.
As far as I know, the builtin varyings are gl_TexCoord[i] where i <
MaxTe
On Fri, Jan 29, 2010 at 8:49 PM, Keith Whitwell wrote:
> So the nv40 code is doing the wrong thing... :)
>
> The rule currently is that the generic tags are just tags and are used only
> to establish mapping between fragment shader and vertex shader. Additionaly
> the vertex shader should alwa
On Fri, Jan 29, 2010 at 11:09 PM, Corbin Simpson
wrote:
> I would say that the routing table really needs to be handled by the
> driver implicitly. When you're told to draw things, you do your shader
> routing/linking before you draw.
>
> If the routing table really does depend on the shaders and
On Sun, Jan 31, 2010 at 3:21 PM, José Fonseca wrote:
> On Sat, 2010-01-30 at 04:06 -0800, Corbin Simpson wrote:
>> Handful of random things bugging me.
>
> Bellow some answers for the things I know enough to comment.
>
>> 1) Team Fortress 2 (and probably other Source games, haven't really
>> check
> In GL, there doesn't seem to be a requirement for sequential usage - an app
> using ARB_vp/fp could explicitly pass TEXCOORD[10] and ignore 0..9 if it
> wanted to. In ARB_vp, that effectively means the shader would be using
> discontiguous register numbers, ie OUTPUT[0], OUTPUT[10], etc.
Yes
An overview of the possible options.
Let's call vertex shader outputs "v" and fragment shader inputs "f"
Let v -> f mean that v connects to f.
NUM_INTERPOLATORS is the number of available interpolators. It is
usually between 8 and 32.
1. Current Gallium
v -> f if and only if v == f
Any values of v
On Mon, Feb 1, 2010 at 3:38 PM, Keith Whitwell wrote:
> This seems like a very different idea of semantics. These aren't intended to
> be hardware resources, and there is no concept of querying the driver to
> figure out how many the hardware supports. Further, the indices for
> different sem
> I can't really use a routing table state to produce a cso, because the hw
> routing table I generate depends on rasterizer state, e.g. I must not
> put in back face colour (we have a 2 to 1 mapping here) if twoside
> is disabled.
>
> Also, I'm routing based on the scalar *components* the FP reads
On Mon, Feb 1, 2010 at 5:31 PM, Keith Whitwell wrote:
> Christoph, Luca,
>
> Twoside lighting has is a bit of a special case GL-ism. On a lot of hardware
> we end up implementing it by passing both front and back colors to the
> fragment shader and selecting between them using the FACE variabl
> DX9 semantic indexes are apparently unlimited
According to http://msdn.microsoft.com/en-us/library/ee418355%28VS.85%29.aspx,
this is not the case.
Here is the relevant text:
<<
These semantics have meaning when attached to a vertex-shader
parameters. These semantics are supported in both Direct
> I haven't tried to probe crazy high numbers, but within reason, my experience
> is that the numbers are unconstrained.
No, according to that document if you use TEXCOORD[n] then n < NUM_TEXCOORDS.
<<
TEXCOORD[n] Texture coordinates float4
[...]
n is an optional integer between 0 and th
> Where the semantic indicates some relationship to actual system resources, I
> agree that the number is constrained by the number of those system resources.
> In the case of the gallium "GENERIC" semantic, there is explicitly no system
> resource that semantic is referring to and hence no lim
A possible limitation of this scheme is that it doesn't readily map to
hardware that can configure its own interpolators to behave either as
GENERIC, COLOR (or some other semantic) dynamically.
However, it seems to me that at least ARB_fragment_program only
requires and supports 2 COLOR registers
> At least for SM3.0, one can specify a vertex shader output semantic like
> COLOR15 and have it running as long as one has also a pixel shader with a
> matching input semantic. Though I agree with you we don't really want to go
> this route and have something more sensible.
Do you know of any off
> Personally I'm
> going to take a break from this thread, spend a couple of days looking
> at i965, etc, to see what can be done to improve things there, and
> maybe come back with an alternate proposal.
Yes, I think that the most important step is to precisely determine
how both hardware (and e
On Tue, Feb 2, 2010 at 7:38 PM, Olivier Galibert wrote:
> On Tue, Feb 02, 2010 at 07:09:12PM +0100, Luca Barbieri wrote:
>> Otherwise, we will need to recompile either of the shaders at link
>> time, so that "foo" is assigned the same slot in both shaders, which
>
I tested this on Windows, using nVidia driver 195 on nv40, and it
seems we are all partially wrong.
SM3 does indeed allow semantics unrelated to hardware resources.
However, the semantic indices for any semantic type must be in the
range 0-15, or D3DX will report a compiler error during shader
com
> By making transfers context-private and non-shareable, it becomes
> possible for a driver to implement interleaved drawing and dma-uploads
> within a single command buffer.
While we do this, how about removing transfer map and unmap functions
and making the create and destroy functions do mappin
> Map/unmap make it all the way to the user's program, and there will
> likely be cases where user code maps/unmaps a buffer multiple times
> before drawing. The current transfer semantics can handle that with
> zero-copy if the state tracker does the right thing with it.
OpenGL does not allow you
> Instead of combining create/map and
> unmap/destroy it would be better to make map more powerful.
If I understand correctly, you are proposing to add a subrectangle
parameter to map/unmap, so that you can collect multiple rectangle
updates in a single upload happening at transfer destruction tim
Depends on previous signalled value patch.
If the reqiest is unsynchronized, we must not do anything, so do that
check first.
Fixes a bug if DONTBLOCK | UNSYNCHRONIZED.
---
.../auxiliary/pipebuffer/pb_buffer_fenced.c| 34 +--
1 files changed, 16 insertions(+), 18 delet
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/src/
If the size is lower than the alignment, we must use the alignment to
select the bucket.
Otherwise, the selected bucket won't be able to satisfy our request
and will fail.
---
src/gallium/auxiliary/pipebuffer/pb_bufmgr_slab.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff -
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 95eb5f6..d97
If a fragment program uses a semantic/index pair which is not
mentioned by the vertex program, or is mentioned but the corresponding
register is never written to, what happens?
Is the value undefined or intialized to (0, 0, 0, 1)?
OpenGL seems to specify that such values are undefined, and of cou
> I have some doubts about this patch though. It is impossible to satisfy
> both DONTBLOCK and UNSYNCHRONIZED flags simultaneously, so the result of
> specifying both is implementation dependent. Why should UNSYNCHRONIZED
> be favored over DONTBLOCK?
I think that is the correct choice given the cu
> 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® Parallel S
> + if (flags & PIPE_BUFFER_USAGE_UNSYNCHRONIZED) {
This should be:
if (!(flags & PIPE_BUFFER_USAGE_UNSYNCHRONIZED)) {
Sorry for this.
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Spe
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 introduc
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
syntax)
> At some stage we're definitely interested in the gpu_program4 extension.
> I'm not sure the older ones will ever be pulled in.
swrast already supports NV_fragment_program_option (nv30) and
NV_vertex_program_1_1 (nv20).
nv30/nv40 support of those should be easy, but requires to extend TGSI
with co
1 - 100 of 249 matches
Mail list logo
