We'll need to write this register to start/stop performance counters.
Signed-off-by: Kenneth Graunke
Cc: Eric Anholt
Cc: Carl Worth
Cc: Juha-Pekka Heikkilä
---
src/mesa/drivers/dri/i965/intel_reg.h | 4
1 file changed, 4 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_reg.h
Unfortunately, our hardware only has one set of aggregating performance
counters shared between all 3D programs, and their values are not saved
or restored by hardware contexts. Also, at least on Sandybridge and
Ivybridge, the counters lose their values if the GPU goes to sleep.
To work around bo
Signed-off-by: Kenneth Graunke
Cc: Eric Anholt
Cc: Carl Worth
Cc: Juha-Pekka Heikkilä
---
.../drivers/dri/i965/brw_performance_monitor.c | 42 ++
1 file changed, 42 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_performance_monitor.c
b/src/mesa/drivers/dri/i
We need to start OA at the beginning of each batch where monitors are
active. OACONTROL isn't part of the hardware context, so to avoid
leaving counters enabled for other applications, we turn them off at the
end of the batch too.
We also need to start them at BeginPerfMonitor time (unless they'v
In order to use the Observability Architecture effectively, we'll need
to take snapshots of the OA counters via MI_REPORT_PERF_COUNT at the
start and end of each batch.
Experimentation reveals that we need to flush before and after each
MI_REPORT_PERF_COUNT to get working values. For simplicitly,
XXX: Gen6+ needs to be predicated on register writes.
our register write checking function doesn't work on Gen6.
(this patch will be replaced; I'd just like to send the others up for
review sooner rather than later)
Signed-off-by: Kenneth Graunke
Cc: Eric Anholt
Cc: Carl Worth
Cc: Juha-Pekka
Currently, this only considers the monitor start and end snapshots.
This is woefully insufficient, but allows me to add a bunch of the
infrastructure now and flesh it out later.
Signed-off-by: Kenneth Graunke
Cc: Eric Anholt
Cc: Carl Worth
Cc: Juha-Pekka Heikkilä
---
.../drivers/dri/i965/brw_
https://bugs.freedesktop.org/show_bug.cgi?id=71591
Kenneth Graunke changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=71591
Michel Dänzer changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
If a performance monitor has never ended, then no result can be
available. Core Mesa can easily handle this, saving drivers a tiny bit
of complexity.
Signed-off-by: Kenneth Graunke
Cc: Eric Anholt
Cc: Carl Worth
Cc: Juha-Pekka Heikkilä
---
src/mesa/main/performance_monitor.c | 6 +-
1 fi
This is fairly simple:
- At BeginPerfMonitor time, take an opening snapshot.
- At EndPerfMonitor time, take a closing snapshot.
- The first time the application asks for results, subtract the two and
store that value. Then free the BO containing the snapshots.
- On subsequent requests for the re
MI_REPORT_PERF_COUNT writes a snapshot of the Observability Architecture
counters to a buffer. Exactly how it works varies between generations:
Ironlake requires two packets, Sandybridge has to use GGTT, and Ivybridge
and later use PPGTT.
v2: Assert that we didn't use more space than we reserved
Signed-off-by: Kenneth Graunke
Cc: Eric Anholt
Cc: Carl Worth
Cc: Juha-Pekka Heikkilä
---
.../drivers/dri/i965/brw_performance_monitor.c | 38 +-
1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_performance_monitor.c
b/src/mes
The Observability Architecture counters are 32-bit unsigned values, and
the Pipeline Statistics Register counters are 64-bit unsigned values.
These convenience macros make it easy to create those types of counters.
Signed-off-by: Kenneth Graunke
Cc: Eric Anholt
Cc: Carl Worth
Cc: Juha-Pekka He
Previously, brw_new_batch was called just after execbuf, but before
intel_batchbuffer_reset. Essentially, it prepared for the creation of a
new batch, that wasn't yet available, and which it didn't create. This
was a bit awkward.
This patch makes brw_new_batch call intel_batchbuffer_reset as the
If a monitor has ended, it means a result should eventually become
available, pending some flushing.
This is distinct from !m->Active; if a monitor has not been started,
then m->Active == false and m->Ended == false.
Signed-off-by: Kenneth Graunke
Cc: Eric Anholt
Cc: Carl Worth
Cc: Juha-Pekka
Since we don't support any counters, there are zero groups.
Signed-off-by: Kenneth Graunke
Cc: Eric Anholt
Cc: Carl Worth
Cc: Juha-Pekka Heikkilä
---
.../drivers/dri/i965/brw_performance_monitor.c | 36 +-
1 file changed, 35 insertions(+), 1 deletion(-)
diff --git a/s
When we first create a batch buffer, it's empty. We don't actually
know what ring it will be targeted at until the first BEGIN_BATCH or
BEGIN_BATCH_BLT macro.
Previously, one could determine the state of the batch by checking
brw->batch.is_blit (blit vs. render) and brw->batch.used != 0 (known vs
It's useful to see the state of all outstanding monitors; the start
of a new batch seems like a reasonable time to print them out.
Signed-off-by: Kenneth Graunke
Cc: Eric Anholt
Cc: Carl Worth
Cc: Juha-Pekka Heikkilä
---
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 3 +++
1 file changed, 3
For now, we only support these on Gen6+, since that's what currently
uses hardware contexts. When we add Ironlake hardware context support,
we can add pipeline statistics register support for that as well.
In theory, we could support pipeline statistics counters even without
hardware contexts, bu
The new intel_batchbuffer_emit_render_ring_prelude() hook will be called
when switching from BLT or UNKNOWN_RING to RENDER_RING. This provides a
place to emit state that should go at the start of each render ring
batch, with minimal overhead.
Signed-off-by: Kenneth Graunke
Cc: Eric Anholt
Cc: C
In addition to listing the counter names, we include several "remap"
tables. Confusingly, counters are documented with names like "A23",
are written to some buffer offset other than 23, and exposed by core
Mesa under a counter ID that is different still.
The first is inevitable; MI_REPORT_PERF_CO
Using the OA counters requires some per-batch work. When starting and
ending a batch, it's useful to know whether any monitors are actually
interested in OA data.
Signed-off-by: Kenneth Graunke
Cc: Eric Anholt
Cc: Carl Worth
Cc: Juha-Pekka Heikkilä
---
src/mesa/drivers/dri/i965/brw_context.h
Without hardware contexts, the pipeline statistics registers are
free-running and include data from every 3D application running.
In order to find out the contributions of one particular context, we
need to take a snapshot at the start and end of each batch.
Previously, we emitted the PIPE_CONTRO
This will enable debugging printfs for the AMD_performance_monitor code.
Signed-off-by: Kenneth Graunke
Cc: Eric Anholt
Cc: Carl Worth
Cc: Juha-Pekka Heikkilä
---
src/mesa/drivers/dri/i965/intel_debug.c | 1 +
src/mesa/drivers/dri/i965/intel_debug.h | 1 +
2 files changed, 2 insertions(+)
di
Being able to print monitor->Name is really useful for debugging.
Signed-off-by: Kenneth Graunke
Cc: Eric Anholt
Cc: Carl Worth
Cc: Juha-Pekka Heikkilä
---
src/mesa/main/mtypes.h | 2 ++
src/mesa/main/performance_monitor.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/sr
These stub functions will be filled out in later patches.
Signed-off-by: Kenneth Graunke
Cc: Eric Anholt
Cc: Carl Worth
Cc: Juha-Pekka Heikkilä
---
src/mesa/drivers/dri/i965/Makefile.sources | 1 +
src/mesa/drivers/dri/i965/brw_context.c| 4 +
src/mesa/drivers/dri/i965
It really makes more sense here.
Signed-off-by: Kenneth Graunke
Cc: Eric Anholt
Cc: Carl Worth
Cc: Juha-Pekka Heikkilä
---
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer
The i965 implementation uses calloc, so I missed this. It's best to
simply initialize it to avoid requiring a zeroing allocator, though.
Signed-off-by: Kenneth Graunke
Cc: Eric Anholt
Cc: Carl Worth
Cc: Juha-Pekka Heikkilä
---
src/mesa/main/performance_monitor.c | 2 ++
1 file changed, 2 ins
The series is
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
h
Reviewed-by: Chris Forbes
Without any docs, I don't feel qualified enough to review beyond this
patch, but it looks generally sensible.
On Wed, Nov 13, 2013 at 2:50 PM, Kenneth Graunke wrote:
> We'll need this for Broadwell code as well.
>
> Normally, when we make things public, we add the "brw
Reviewed-by: Chris Forbes
On Wed, Nov 13, 2013 at 2:50 PM, Kenneth Graunke wrote:
> Broadwell code should not include brw_eu.h (since it is for Gen4-7
> assembly encoding), but needs the URB write flags enum.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/brw_defines.h |
That's very nice Jose! Looks good to me.
- Original Message -
> From: José Fonseca
>
> It is similar to tgsi_exec.c's DEBUG_EXECUTION compile flag.
>
> I had prototyped this for a while while debugging an issue, but finally
> cleaned this up and added a few more bells and whistles.
>
This patch is Reviewed-by: Chris Forbes
This does impact on the dual-simd8 texture support, but that should be
fixable similarly.
-- Chris
On Thu, Nov 14, 2013 at 12:51 PM, Anuj Phogat wrote:
> On Tue, Nov 12, 2013 at 5:50 PM, Kenneth Graunke
> wrote:
>> Only Gen4 color write setup uses the
On Wed, Nov 13, 2013 at 5:56 PM, Alexander von Gluck IV
wrote:
* Inherit gl_context so we always have access to it
* Thanks curro for the idea.
* Last Haiku cannidate for 10.0.0
---
src/mesa/drivers/haiku/swrast/SoftwareRast.cpp | 56
+++-
src/mesa/drivers/haiku/swrast/S
* Inherit gl_context so we always have access to it
* Thanks curro for the idea.
* Last Haiku cannidate for 10.0.0
---
src/mesa/drivers/haiku/swrast/SoftwareRast.cpp | 56 +++-
src/mesa/drivers/haiku/swrast/SoftwareRast.h |3 +-
2 files changed, 27 insertions(+), 32 del
On Tue, Nov 12, 2013 at 5:50 PM, Kenneth Graunke wrote:
> Only Gen4 color write setup uses the force_sechalf flag, and it only
> sets it on a single instruction. It also already has to get a pointer
> to the instruction and manually set the saturate flag, so we may as well
> just set force_sechal
Kristian Høgsberg writes:
> On Tue, Nov 12, 2013 at 12:15 PM, Eric Anholt wrote:
>> Kristian Høgsberg writes:
>>
>>> Drivers that only call getBuffers to request color buffers can use these
>>> generic, __DRIimage based helpers to implement the allocBuffer and
>>> releaseBuffer functions of __D
The array was 64kb per struct gl_program, plus we statically stored a copy
of one on disk for _mesa_DummyProgram. Given that most struct gl_programs
we generate are for GLSL shaders that don't have local parameters, this
was a waste.
Since you can store and fetch parameters beyond what the progra
This has been replaced with referring to local parameters using
PROGRAM_STATE_VAR and _mesa_load_state_parameters.
---
src/mesa/drivers/dri/i915/i915_fragprog.c | 3 ---
src/mesa/drivers/dri/r200/r200_vertprog.c | 1 -
src/mesa/main/mtypes.h | 1 -
src/mesa/program/prog_execu
This has been replaced with referring to env parameters using
PROGRAM_STATE_VAR and _mesa_load_state_parameters.
---
src/mesa/drivers/dri/i915/i915_fragprog.c | 8
src/mesa/drivers/dri/r200/r200_vertprog.c | 1 -
src/mesa/main/mtypes.h | 8 +++-
src/mesa/program/
Notably, ENV and LOCAL aren't used any more (replaced by STATE_VAR), but
apparently CONSTANT is.
---
src/mesa/program/program_parser.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/program/program_parser.h
b/src/mesa/program/program_parser.h
index ca36bb6..04c64f4 1
On 11/13/2013 03:32 PM, Jose Fonseca wrote:
- Original Message -
On 11/13/2013 10:37 AM, jfons...@vmware.com wrote:
From: José Fonseca
It is similar to tgsi_exec.c's DEBUG_EXECUTION compile flag.
I had prototyped this for a while while debugging an issue, but finally
cleaned this up
Can I call that a Reviewed-by on the same patch that I sent on Monday?
http://lists.freedesktop.org/archives/mesa-dev/2013-November/048198.html
On 11/13/2013 01:26 PM, Kenneth Graunke wrote:
> Cc: Ian Romanick
> Cc: "10.0"
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/common/u
"Armin K." writes:
> On 13.11.2013 1:08, Eric Anholt wrote:
>> After more testing (everyone else trying to build the stack is having as
>> much trouble as I had, even after the problems I had were fixed), it
>> really feels like dri3 is not something we're ready to support in this
>> stable branc
For both vertex and fragment shaders we default MaxUniformComponents
to 4 * MAX_UNIFORMS. It makes sense to do this for geometry shaders
too; if back-ends have different limits they can override them as
necessary.
Fixes piglit test:
spec/glsl-1.50/built-in constants/gl_MaxGeometryUniformComponent
- Original Message -
> On 11/13/2013 10:37 AM, jfons...@vmware.com wrote:
> > From: José Fonseca
> >
> > It is similar to tgsi_exec.c's DEBUG_EXECUTION compile flag.
> >
> > I had prototyped this for a while while debugging an issue, but finally
> > cleaned this up and added a few more bel
Cc: Ian Romanick
Cc: "10.0"
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/common/utils.c | 2 +-
src/mesa/drivers/dri/common/utils.h | 2 +-
src/mesa/drivers/dri/i965/intel_screen.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/c
On Tue, Nov 12, 2013 at 5:51 PM, Kenneth Graunke wrote:
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/brw_vec4_gs.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_gs.c
> b/src/mesa/drivers/dri/i965/brw_vec4_gs.c
> index b52
On 11/10/2013 05:42 AM, Alexander Monakov wrote:
> Ping. A week ago a few people who looked at the older version of this
> patch posted on IRC didn't point out obvious flaws. Can this get a
> review please?
Looks good to me. Pushed, thanks!
___
mesa-
The introduction and use of lp_build_clamp_zero_one_nanzero looks good.
I can't comment on the changes to the existing paths though, as they are too
subtle for me. As long there are no regressions I'm good.
Jose
- Original Message -
> From: Roland Scheidegger
>
> d3d10 requires us to
On Wed, Nov 13, 2013 at 1:12 PM, Tom Stellard wrote:
> On Wed, Nov 13, 2013 at 12:27:05PM -0500, Alex Deucher wrote:
>> Signed-off-by: Alex Deucher
>
> Reviewed-by: Tom Stellard
>
> Now that we have compute support for Sea Islands, we will also need to
> add the processor to clang. I can take c
On Wed, Nov 13, 2013 at 1:08 PM, Tom Stellard wrote:
> On Wed, Nov 13, 2013 at 12:29:31PM -0500, Alex Deucher wrote:
>> Update additional register fields.
>>
>> Signed-off-by: Alex Deucher
>
> Should we CC: mesa-stable on these?
Probably not at this point. Support is still pretty unstable on
Ha
On Wed, 13 Nov 2013 11:33:44 -0800
Kenneth Graunke wrote:
> On 11/13/2013 08:47 AM, Alexander von Gluck IV wrote:
> > On Wed, 13 Nov 2013 08:38:59 -0700
> > Brian Paul wrote:
> >
> >> On 11/12/2013 10:49 PM, Alexander von Gluck IV wrote:
> >>> On Tue, Nov 12, 2013 at 11:46 PM, Alexander von Gluc
And simplify the code.
---
src/gallium/drivers/svga/svga_draw_elements.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_draw_elements.c
b/src/gallium/drivers/svga/svga_draw_elements.c
index fb5f1c9..117f2b0 100644
--- a/src/gall
On 11/13/2013 08:47 AM, Alexander von Gluck IV wrote:
> On Wed, 13 Nov 2013 08:38:59 -0700
> Brian Paul wrote:
>
>> On 11/12/2013 10:49 PM, Alexander von Gluck IV wrote:
>>> On Tue, Nov 12, 2013 at 11:46 PM, Alexander von Gluck IV
>>> wrote:
* This is pretty small and upkeep
should b
On 11/13/2013 10:37 AM, jfons...@vmware.com wrote:
From: José Fonseca
It is similar to tgsi_exec.c's DEBUG_EXECUTION compile flag.
I had prototyped this for a while while debugging an issue, but finally
cleaned this up and added a few more bells and whistles.
Here is a sample output.
CONST[0
To resolve missing symbol since the DRI driver rearchitecting.
---
src/gallium/targets/dri-vmwgfx/target.c | 16
1 file changed, 16 insertions(+)
diff --git a/src/gallium/targets/dri-vmwgfx/target.c
b/src/gallium/targets/dri-vmwgfx/target.c
index e01e465..b4aaf0a 100644
--- a/
The index translation code expects the number of indexes to be
consistent with the primitive type (ex: a multiple of 3 for
PIPE_PRIM_TRIANGLES). If it's not, we can write out of bounds
in the destination buffer.
Fixes failed assertions in the pipebuffer debug code found with
Piglit primitive-rest
---
src/gallium/auxiliary/indices/u_indices.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/src/gallium/auxiliary/indices/u_indices.c
b/src/gallium/auxiliary/indices/u_indices.c
index 30b54b9..1b33f41 100644
--- a/src/gallium/auxiliary/indices/u_indices.c
+++ b
---
src/mesa/main/varray.h |6 --
1 file changed, 6 deletions(-)
diff --git a/src/mesa/main/varray.h b/src/mesa/main/varray.h
index 3b9f39a..bc820ed 100644
--- a/src/mesa/main/varray.h
+++ b/src/mesa/main/varray.h
@@ -110,12 +110,6 @@ extern void GLAPIENTRY
_mesa_VertexPointer(GLint size
To trim down the varray.c file so it's just vertex array functions.
---
src/mapi/glapi/gen/gl_genexec.py |1 +
src/mesa/Makefile.sources|1 +
src/mesa/SConscript |1 +
src/mesa/drivers/common/meta.c |1 +
src/mesa/main/draw.c |
Looks great to me. Just some minor nitpicks.
On 11/13/2013 05:37 PM, jfons...@vmware.com wrote:
From: José Fonseca
It is similar to tgsi_exec.c's DEBUG_EXECUTION compile flag.
I had prototyped this for a while while debugging an issue, but finally
cleaned this up and added a few more bells an
On Wed, Nov 13, 2013 at 12:27:05PM -0500, Alex Deucher wrote:
> Signed-off-by: Alex Deucher
Reviewed-by: Tom Stellard
Now that we have compute support for Sea Islands, we will also need to
add the processor to clang. I can take care of this.
-Tom
> ---
> lib/Target/R600/Processors.td | 1 +
On Wed, Nov 13, 2013 at 12:29:31PM -0500, Alex Deucher wrote:
> Update additional register fields.
>
> Signed-off-by: Alex Deucher
Should we CC: mesa-stable on these?
> ---
> src/gallium/drivers/radeonsi/radeonsi_pipe.c | 2 ++
> src/gallium/drivers/radeonsi/si_state.c | 4
From: José Fonseca
It is similar to tgsi_exec.c's DEBUG_EXECUTION compile flag.
I had prototyped this for a while while debugging an issue, but finally
cleaned this up and added a few more bells and whistles.
Here is a sample output.
CONST[0]:
X: 0.006250 0.006250 0.006250 0.006250
Y: -0.0
On 11/11/13 18:53, Emil Velikov wrote:
> Hello list,
>
> Here is an updated version of the subdir-objects series sent earlier.
>
> As a reminder the series aims to
> * make mesa build system "subdir-objects" compliant
> * minimise flags duplication across gallium
>
> Changes since previous versi
Signed-off-by: Alex Deucher
---
lib/Target/R600/Processors.td | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/Target/R600/Processors.td b/lib/Target/R600/Processors.td
index 31079d3..ee190e4 100644
--- a/lib/Target/R600/Processors.td
+++ b/lib/Target/R600/Processors.td
@@ -51,3 +51,4 @@ d
Signed-off-by: Alex Deucher
---
include/pci_ids/radeonsi_pci_ids.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/pci_ids/radeonsi_pci_ids.h
b/include/pci_ids/radeonsi_pci_ids.h
index 0fdd1ad..7b42d5e 100644
--- a/include/pci_ids/radeonsi_pci_ids.h
+++ b/include/pci_i
Update additional register fields.
Signed-off-by: Alex Deucher
---
src/gallium/drivers/radeonsi/radeonsi_pipe.c | 2 ++
src/gallium/drivers/radeonsi/si_state.c | 4
src/gallium/drivers/radeonsi/sid.h| 9 +
src/gallium/winsys/radeon/drm/radeon_drm_winsy
On 11/13/2013 08:43 AM, Ferry Huberts wrote:
On 13/11/13 16:42, Ferry Huberts wrote:
The link in
https://urldefense.proofpoint.com/v1/url?u=http://cgit.freedesktop.org/mesa/mesa/diff/docs/index.html?id%3D9976a176ae62d53e8ad0c0f934d207e22ac41e85&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=lGQMzzTgII0
On 11/13/2013 09:47 AM, Alexander von Gluck IV wrote:
On Wed, 13 Nov 2013 08:38:59 -0700
Brian Paul wrote:
On 11/12/2013 10:49 PM, Alexander von Gluck IV wrote:
On Tue, Nov 12, 2013 at 11:46 PM, Alexander von Gluck IV
wrote:
* This is pretty small and upkeep
should be minimal.
Can you
On Wed, 13 Nov 2013 08:38:59 -0700
Brian Paul wrote:
> On 11/12/2013 10:49 PM, Alexander von Gluck IV wrote:
> > On Tue, Nov 12, 2013 at 11:46 PM, Alexander von Gluck IV
> > wrote:
> >> * This is pretty small and upkeep
> >> should be minimal.
>
> Can you combine those two lines (70 chars per
On 13/11/13 16:42, Ferry Huberts wrote:
The link in
http://cgit.freedesktop.org/mesa/mesa/diff/docs/index.html?id=9976a176ae62d53e8ad0c0f934d207e22ac41e85
is wrong, points to 9.2.2 i.s.o. 9.2.3
ah, and here as well
http://cgit.freedesktop.org/mesa/mesa/diff/docs/relnotes.html?id=9976a176ae62
The link in
http://cgit.freedesktop.org/mesa/mesa/diff/docs/index.html?id=9976a176ae62d53e8ad0c0f934d207e22ac41e85
is wrong, points to 9.2.2 i.s.o. 9.2.3
--
Ferry Huberts
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedeskto
On 11/12/2013 10:49 PM, Alexander von Gluck IV wrote:
On Tue, Nov 12, 2013 at 11:46 PM, Alexander von Gluck IV
wrote:
* This is pretty small and upkeep
should be minimal.
Can you combine those two lines (70 chars per line is about right for
git commit messages)?
Perhaps the subject line
Mesa 9.2.3 has been released. Mesa 9.2.3 is a bug fix release which
fixes bugs fixed since the 9.2.2 release.
The tag in the git repository for Mesa 9.2.3 is 'mesa-9.2.3'.
Mesa 9.2.3 is available for download at
ftp://freedesktop.org/pub/mesa/9.2.3/
md5sums:
66e9a33a414f801e1c33398bf627d56b Me
From: Ander Conselvan de Oliveira
Both __DRIimage and intel_region have width and height fields. They
actually differ when an image is created for a texture but are the
same in all the other cases. For images created from a planar image,
a special intel_region that represents only a part of the s
https://bugs.freedesktop.org/show_bug.cgi?id=71575
Kevin Rogovin changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=71575
--- Comment #1 from Kevin Rogovin ---
Created attachment 89138
--> https://bugs.freedesktop.org/attachment.cgi?id=89138&action=edit
Fragment shader of program.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=71575
Priority: medium
Bug ID: 71575
Assignee: mesa-dev@lists.freedesktop.org
Summary: Long expressions in shaders crash Mesa
Severity: normal
Classification: Unclassified
OS: All
81 matches
Mail list logo
