I'm hoping to add support for doing the transform feedback queries in
hardware, rather than software counters (as geometry shaders will break
the CPU-side counting.)
Before I could do that, I had to make the query object code a bit more
understandable, and eliminate globals specific to occlusion q
In OpenGL, most queries record statistics about operations performed
between a defined beginning and ending point. However, TIMESTAMP
queries are different: they immediately return a single value, and there
is no start/stop mechanism.
Previously, Mesa implemented TIMESTAMP queries by calling EndQ
This moves the GL_TIMESTAMP handling out of EndQuery.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_queryobj.c | 27 +--
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_queryobj.c
b/src/mesa/drivers/dri/i965
For timestamp queries, we just write a single value to a BO. The
natural place to write that is element 0, so we should do that.
Previously, we wrote it into element 1 (the second slot) leaving
element 0 filled with garbage.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_quer
This code was really difficult to follow, for a number of reasons:
- Queries were handled in four different ways (TIMESTAMP writes a single
value, TIME_ELAPSED writes a single pair of values, occlusion queries
write pairs of values for the start and end of each batch, and other
queries are d
brw->query.index is initialized to 0 just a few lines before it's
copied to first_index.
Presumably the idea here was to reuse the query BO for subsequent
queries of the same type, but since that doesn't happen, there's no need
to have the extra code complexity.
Signed-off-by: Kenneth Graunke
--
If we haven't allocated a BO yet, we need to do that. Or, if there
isn't enough room to write another pair of values, we need to gather up
the existing results and start a new one. This is simple enough.
However, the old code was awkwardly split into two blocks, with a
write_depth_count() placed
Since we already have an index in the brw_query_object, there's no need
to also keep a global variable that shadows it.
Plus, if we ever add support for more types of queries that still need
the per-batch before/after treatment we do for occlusion queries, we
won't be able to use a single global v
The code a few lines above calls brw_emit_query_begin() if !query->bo,
and that creates query->bo. So it should always be non-NULL.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_queryobj.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/mesa
Again, eliminating a global variable in favor of a per-query object
variable will help in a future where we have more queries in hardware.
Personally, I find this clearer: there's just the query object's BO,
rather than two variables that usually shadow each other.
Signed-off-by: Kenneth Graunke
We'll want to reuse this for non-occlusion queries in the future.
Plus, it's a single logical task, so having it as a helper function
clarifies the code somewhat.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_queryobj.c | 56 +++-
1 file changed, 3
TF2 doesn't use CP DMA with this patch at all, so I'm not seeing any
issue obviously. This patch is an optimization, not a workaround. It
also doesn't affect CP DMA in any way. It only detects when a buffer
range can be mapped without the CPU-GPU synchronization, which is the
most efficient way of
On Thu, Feb 28, 2013 at 12:50 AM, Brian Paul wrote:
> On 02/27/2013 04:11 PM, Marek Olšák wrote:
>>
>> ---
>> src/gallium/auxiliary/util/u_range.h | 91
>> ++
>> 1 file changed, 91 insertions(+)
>> create mode 100644 src/gallium/auxiliary/util/u_range.h
>>
>>
On 02/27/2013 04:58 PM, Eric Anholt wrote:
From: Paul Berry
This bug is currently benign, since get_called_parameter_string() is
currently only used for functions that return true for
glx_function.has_different_protocol(), and none of those functions
include padding. However, in order to imple
https://bugs.freedesktop.org/show_bug.cgi?id=61415
Francisco Jerez changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
All the Wine D3D tests now (3931289ab5fc7c7e2ab46e6316e55adc19ec3cfc)
pass for me on Cayman. I may be able to do some more testing later,
and do e.g. a piglit run.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailm
On February 28, 2013 12:19:30 PM Vadim Girlin wrote:
> > Do you still need some piglit test on rv790 hardware? I've also tried
> > running Serious Sam 3 with the standard, llvm and your optimized backend
> > and SS3 finally manages to not be a slideshow above the lowest settings.
> > Great improvem
On Thu, Feb 28, 2013 at 4:05 AM, Marek Olšák wrote:
> TF2 doesn't use CP DMA with this patch at all, so I'm not seeing any
> issue obviously. This patch is an optimization, not a workaround. It
> also doesn't affect CP DMA in any way. It only detects when a buffer
> range can be mapped without the
https://bugs.freedesktop.org/show_bug.cgi?id=61455
José Fonseca changed:
What|Removed |Added
CC||bri...@vmware.com,
|
https://bugs.freedesktop.org/show_bug.cgi?id=61366
José Fonseca changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=61299
José Fonseca changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=60706
José Fonseca changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Thu, Feb 28, 2013 at 4:26 PM, Alex Deucher wrote:
> On Thu, Feb 28, 2013 at 4:05 AM, Marek Olšák wrote:
>> TF2 doesn't use CP DMA with this patch at all, so I'm not seeing any
>> issue obviously. This patch is an optimization, not a workaround. It
>> also doesn't affect CP DMA in any way. It o
On Thu, Feb 28, 2013 at 11:11 AM, Marek Olšák wrote:
> On Thu, Feb 28, 2013 at 4:26 PM, Alex Deucher wrote:
>> On Thu, Feb 28, 2013 at 4:05 AM, Marek Olšák wrote:
>>> TF2 doesn't use CP DMA with this patch at all, so I'm not seeing any
>>> issue obviously. This patch is an optimization, not a wo
This requirement was added by ARB_fragment_program
When the Steam overlay is enabled, this fixes:
* Menu corruption with the Puddle game
* The screen going black on Rochard when
the Steam overlay is accessed
NOTE: This is a candidate for the 9.0 and 9.1 branches.
Signed-off-by: Jordan Justen
On 02/28/2013 09:29 AM, Jordan Justen wrote:
This requirement was added by ARB_fragment_program
When the Steam overlay is enabled, this fixes:
* Menu corruption with the Puddle game
* The screen going black on Rochard when
the Steam overlay is accessed
NOTE: This is a candidate for the 9.0 a
On Thu, Feb 28, 2013 at 3:58 AM, Daniel Martin wrote:
>
> Signed-off-by: Daniel Martin
> ---
> There's a small logic error preventing mesa to be build with swrast only
> and not having libdrm.
>
> configure.ac |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/configu
https://bugs.freedesktop.org/show_bug.cgi?id=61455
--- Comment #2 from Keith Kriewall ---
The mesa demo wincopy uses glMakeContextCurrent. If you need a test case
beyond this, please let me know.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=61455
--- Comment #3 from José Fonseca ---
mesademos/src/xdemos/wincopy.c is an X11 sample, not WGL. And to test this I'd
really need a wglMakeContextCurrentARB.
Please note that, spite the similarties between glXMakeContextCurrent and
wglMakeContext
https://bugs.freedesktop.org/show_bug.cgi?id=61455
--- Comment #4 from Keith Kriewall ---
OK, we'll look at porting wincopy to Windows, or writing another test
application. We're booked up for several days, but I'll get it to you ASAP.
--
You are receiving this mail because:
You are the assign
Chad Versace writes:
> On 02/27/2013 11:39 AM, Eric Anholt wrote:
>> Chad Versace writes:
>>
>>> On 02/26/2013 11:15 PM, Eric Anholt wrote:
I have some debug of HiZ rendering that looks like some rendering is not
landing in my HiZ buffer. Unfortunately, fulsim choking on us violating
Kenneth Graunke writes:
> brw->query.index is initialized to 0 just a few lines before it's
> copied to first_index.
>
> Presumably the idea here was to reuse the query BO for subsequent
> queries of the same type, but since that doesn't happen, there's no need
> to have the extra code complexity
Kenneth Graunke writes:
> We'll want to reuse this for non-occlusion queries in the future.
>
> Plus, it's a single logical task, so having it as a helper function
> clarifies the code somewhat.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/brw_queryobj.c | 56
>
Kenneth Graunke writes:
> This code was really difficult to follow, for a number of reasons:
>
> - Queries were handled in four different ways (TIMESTAMP writes a single
> value, TIME_ELAPSED writes a single pair of values, occlusion queries
> write pairs of values for the start and end of ea
Kenneth Graunke writes:
> If we haven't allocated a BO yet, we need to do that. Or, if there
> isn't enough room to write another pair of values, we need to gather up
> the existing results and start a new one. This is simple enough.
>
> However, the old code was awkwardly split into two blocks
Matt Turner writes:
> diff --git a/configure.ac b/configure.ac
> index 9178355..f25d488 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -732,6 +732,7 @@ if test "x$enable_glx" = xyes -a \
> enable_glx=no
> fi
>
> +AM_CONDITIONAL(HAVE_GLX, test "x$enable_glx" = xyes)
Looks like we'll
Signed-off-by: Daniel Martin
---
There's a small logic error preventing mesa to be build with swrast only
and not having libdrm.
v2: "|| test" replaced by "-a"
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 5f95a78..7852595 10
On 02/28/2013 08:29 AM, Jordan Justen wrote:
This requirement was added by ARB_fragment_program
When the Steam overlay is enabled, this fixes:
* Menu corruption with the Puddle game
* The screen going black on Rochard when
the Steam overlay is accessed
NOTE: This is a candidate for the 9.0 a
On 02/28/2013 09:08 AM, Eric Anholt wrote:
Chad Versace writes:
On 02/27/2013 11:39 AM, Eric Anholt wrote:
Chad Versace writes:
On 02/26/2013 11:15 PM, Eric Anholt wrote:
I have some debug of HiZ rendering that looks like some rendering is not
landing in my HiZ buffer. Unfortunately, ful
On 02/28/2013 11:01 AM, Kenneth Graunke wrote:
> On 02/28/2013 09:08 AM, Eric Anholt wrote:
>> Chad Versace writes:
>>
>>> On 02/27/2013 11:39 AM, Eric Anholt wrote:
Chad Versace writes:
> On 02/26/2013 11:15 PM, Eric Anholt wrote:
>> I have some debug of HiZ rendering that look
On Tue, Feb 26, 2013 at 9:51 AM, Kenneth Graunke wrote:
>> diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
>> b/src/mesa/drivers/dri/i965/brw_shader.cpp
>> index 9ab18cc..6965d72 100644
>> --- a/src/mesa/drivers/dri/i965/brw_shader.cpp
>> +++ b/src/mesa/drivers/dri/i965/brw_shader.cpp
>> @@
On Tue, Feb 26, 2013 at 10:31 AM, Ian Romanick wrote:
> On 02/19/2013 05:03 PM, Matt Turner wrote:
>>
>> ---
>> src/glsl/opt_algebraic.cpp | 16 +---
>> 1 files changed, 13 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
>>
https://bugs.freedesktop.org/show_bug.cgi?id=61361
--- Comment #3 from Andreas Boll ---
Could you try to build from git?
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
This is a merge of Bryan's gs patches plus some work on top of them
that fixes the known issues with geometry shaders in the draw module.
I had to fix the llvm paths in the "account for separate shader objects"
commit because it broke them.
With this both softpipe and llvmpipe have working geometry
From: Bryan Cain
Before, it accounted for the size of the vertices but not the other fields
in the vertex_header struct, which caused memory corruption.
Reviewed-by: Zack Rusin
---
src/gallium/auxiliary/draw/draw_gs.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src
From: Bryan Cain
The geometry shader code seems to have been originally written with the
assumptions that there are the same number of VS outputs as GS outputs and
that VS outputs are in the same order as their corresponding GS inputs. Since
TGSI uses separate shader objects, these are both wrong
From: Bryan Cain
Reviewed-by: Zack Rusin
---
src/gallium/auxiliary/draw/draw_pipe_clip.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_pipe_clip.c
b/src/gallium/auxiliary/draw/draw_pipe_clip.c
index 3110809..eeaaf41 10064
We can't clip and viewport transform the vertices before we let
the geometry shader process them. Lets make sure the generated
vertex shader has both disabled if geometry shader is present.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/draw/draw_llvm.c | 15 ++-
1 file change
On 02/28/2013 11:33 AM, Matt Turner wrote:
On Tue, Feb 26, 2013 at 10:31 AM, Ian Romanick wrote:
On 02/19/2013 05:03 PM, Matt Turner wrote:
---
src/glsl/opt_algebraic.cpp | 16 +---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/src/glsl/opt_algebraic.cpp b
On 02/28/2013 11:20 AM, Matt Turner wrote:
On Tue, Feb 26, 2013 at 9:51 AM, Kenneth Graunke wrote:
diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
b/src/mesa/drivers/dri/i965/brw_shader.cpp
index 9ab18cc..6965d72 100644
--- a/src/mesa/drivers/dri/i965/brw_shader.cpp
+++ b/src/mesa/drivers
On 02/28/2013 02:20 PM, Zack Rusin wrote:
This is a merge of Bryan's gs patches plus some work on top of them
that fixes the known issues with geometry shaders in the draw module.
I had to fix the llvm paths in the "account for separate shader objects"
commit because it broke them.
With this both
Chris Forbes writes:
> - sample count must be the same on all attachments
> - fixedsamplepositions must be the same on all attachments
> (renderbuffers have fixedsamplepositions=true implicitly; only
> multisample textures can choose to have it false)
>
> V2: - fix wrapping to 80 columns, debug m
Jordan Justen writes:
> Using MESA_GL_VERSION_OVERRIDE=3.2 and
> MESA_GLSL_VERSION_OVERRIDE=150 currently fails with piglit's
> shader_runner. For a GLSL 1.50 test, shader_runner wants to
> create a 3.2 core profile for a 1.50 test, but that was not
> working. Also, the compiler would assert duri
Chris Forbes writes:
> Gen7 has an erratum affecting the ld_mcs message, making it unsafe to
> use when the surface doesn't have an associated MCS.
>
> From the Ivy Bridge PRM, Vol4 Part1 p77 ("MCS Enable"):
>
>"If this field is disabled and the sampling engine
>message is issued on this
Hi,
there is some sloppy usage of bind flags in the opengl state tracker
(that is, resources get used for things which they didn't have the bind
flag set).
We'd really like to enforce these flags to be honored but it doesn't
really work (ok llvmpipe so far would only really care about sampler
view
This series lives on my 'hiz-pre' branch.
I have a large hiz series brewing for Haswell. To make review easier,
I decided to post some preliminary patches first rather than posting the hiz
patch bomb all at once. If you'd prefer that I shelve this series until I'm
ready to submit the hiz series
Fix a line to use only spaces. All adjacent lines were using spaces. This
fixes weird indentation.
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.
Performing a hiz operation with an ill-aligned rectangle primitive causes
GPU hanges on some hardware. Later patches will disable hiz on individual
slices to avoid such hangs.
However, this patch introduces no behavioral change. If `mt->hiz_mt` is
set, then this sets `has_hiz` for all slices in
Add two new functions:
intel_miptree_slice_has_hiz
intel_renderbuffer_has_hiz
These functions are not yet used.
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/intel/intel_fbo.c | 7 +++
src/mesa/drivers/dri/intel/intel_fbo.h | 3 +++
src/mesa/drivers/dri/intel/inte
These will later be used to determine if hiz is enabled for the given
slice via intel_miptree_slice_has_hiz().
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/i965/brw_blorp.cpp | 2 ++
src/mesa/drivers/dri/i965/brw_blorp.h | 10 ++
2 files changed, 12 insertions(+)
diff --git a
Add two new parameters, 'level' and 'layer'. A later patch will pass the
new parameters to intel_miptree_slice_has_hiz().
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/i965/brw_context.h| 2 ++
src/mesa/drivers/dri/i965/brw_misc_state.c | 19 ---
src/mesa/drivers/dri/
s/brw_state_upload/brw_upload_state/
Found because the link was broken.
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/i965/brw_draw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
b/src/mesa/drivers/dri/i965/brw_draw.c
index 2c2
That is, replace checks like `hiz_mt != NULL` with
`intel_miptree_slice_has_hiz(...)` where appropriate. This is necessary
because a later patch will selectively disable hiz on individual miptree
slices, and therefore `hiz_mt != NULL` will no longer be a valid
indicator.
This produces no behaviori
This patch (1) extracts from intel_miptree_create() the spaghetti logic
that selects the tiling format, (2) rewrites that spaghetti into a lucid
form, and (3) moves it to a new function, intel_miptree_choose_tiling().
No behavioral change.
As a bonus, it is now evident that the force_y_tiling para
Extract from intel_miptree_create() the logic for selecting
intel_mipmap_tree::format and ::etc_format into a new function,
intel_miptree_select_formats(). No behavioral change.
Now, intel_miptree_create() is short enough to be understandable.
Signed-off-by: Chad Versace
---
src/mesa/drivers/dr
Miptree creation has a workaround for separate stencil buffers. After the
layout is created, we override the tiling to I915_NONE and align it 64x64,
the size of a W-tile.
Before this patch, the workaround occurs in an odd place:
intel_miptree_create(). After brw_miptree_layout() creates the layou
There exist alignment restrictions for the rectangle primitive emitted
during hiz operations. This patch pads the miptree to prevent a correctly
aligned rectangle from writing to out-of-bounds memory.
We do not currently emit a correctly aligned rectangle, though. That
arrives in a later patch.
S
I had to use a debugger to deduce what total_width/height really were.
This patch is for the benefit of those who come after so they don't have
to dig as hard.
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.h | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(
https://bugs.freedesktop.org/show_bug.cgi?id=61640
Priority: medium
Bug ID: 61640
Assignee: mesa-dev@lists.freedesktop.org
Summary: Mesa demos render black without a window manager
present
Severity: minor
Classification:
https://bugs.freedesktop.org/show_bug.cgi?id=46376
Kenneth Graunke changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=61640
Kenneth Graunke changed:
What|Removed |Added
Blocks||46376
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=46376
--- Comment #8 from Brian Paul ---
(In reply to comment #7)
> I managed to bisect this down to:
>
> commit 9a7f84d6b28e180ef79349b36de9a5d58a1e2dc9
> Author: José Fonseca
> Date: Thu Jul 14 17:28:52 2011 +0100
>
> Squashed commit of the
On 02/22/2013 11:27 AM, Jordan Justen wrote:
Using MESA_GL_VERSION_OVERRIDE=3.2 and
MESA_GLSL_VERSION_OVERRIDE=150 currently fails with piglit's
shader_runner. For a GLSL 1.50 test, shader_runner wants to
create a 3.2 core profile for a 1.50 test, but that was not
working. Also, the compiler woul
From: Roland Scheidegger
This was previously only handled for texelFetch (much easier).
Depending on the wrap mode this works slightly differently (for somewhat
efficient implementation), hence have to do that separately in all roughly
137 places - it is easy if we use fixed point coords for wrap
From: Roland Scheidegger
texel offsets should have been the last missing feature (not sure
if anything is actually missing for 140). In any case we still
don't do OpenGL 3.0 (missing MSAA which will be difficult,
plus EXT_packed_float, ARB_depth_buffer_float and EXT_framebuffer_sRGB).
---
src/ga
Force C++ linking of i965_dri.so by adding a dummy C++ source file.
---
src/mesa/drivers/dri/i965/Makefile.am | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/i965/Makefile.am
b/src/mesa/drivers/dri/i965/Makefile.am
index dc140df..77670ef 100644
--- a/src/mesa/drivers/dri/
On Thu, Feb 28, 2013 at 6:21 PM, Frank Henigman wrote:
> Force C++ linking of i965_dri.so by adding a dummy C++ source file.
> ---
> src/mesa/drivers/dri/i965/Makefile.am | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/mesa/drivers/dri/i965/Makefile.am
> b/src/mesa/drivers/dri/i965/
https://bugs.freedesktop.org/show_bug.cgi?id=61647
Priority: medium
Bug ID: 61647
Assignee: mesa-dev@lists.freedesktop.org
Summary: [llvmpipe] lp_texture.c:580:llvmpipe_create_surface:
Assertion `pt->bind & ((1 << 0) | (1 << 1))' faile
Chad Versace writes:
> On 02/28/2013 11:01 AM, Kenneth Graunke wrote:
>> On 02/28/2013 09:08 AM, Eric Anholt wrote:
>>> Chad Versace writes:
>>>
On 02/27/2013 11:39 AM, Eric Anholt wrote:
> Chad Versace writes:
>
>> On 02/26/2013 11:15 PM, Eric Anholt wrote:
>>> I have some
From: Roland Scheidegger
texel offsets should have been the last missing feature (not sure
if anything is actually missing for 140). In any case we still
don't do OpenGL 3.0 (missing MSAA which will be difficult,
plus EXT_packed_float, ARB_depth_buffer_float and EXT_framebuffer_sRGB).
v2: bump t
https://bugs.freedesktop.org/show_bug.cgi?id=61647
--- Comment #1 from Roland Scheidegger ---
Yes, those new assertions essentially catch state tracker bugs. Maybe I should
just disable them for the time being - in this case the state tracker is smart
enough to actually not use the surface but it
https://bugs.freedesktop.org/show_bug.cgi?id=61647
Vinson Lee changed:
What|Removed |Added
CC||srol...@vmware.com
Keywords|
https://bugs.freedesktop.org/show_bug.cgi?id=61361
--- Comment #4 from Dennis Heuer ---
works, but can't run the checks because I have an r200 with no shaders! is the
check configurable?
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=61361
--- Comment #5 from Matt Turner ---
(In reply to comment #4)
> works, but can't run the checks because I have an r200 with no shaders! is
> the check configurable?
huh?
--
You are receiving this mail because:
You are the assignee for the bug.
2013/3/1 :
> From: Roland Scheidegger
>
> texel offsets should have been the last missing feature (not sure
> if anything is actually missing for 140). In any case we still
> don't do OpenGL 3.0 (missing MSAA which will be difficult,
> plus EXT_packed_float, ARB_depth_buffer_float and EXT_framebu
85 matches
Mail list logo
