Re: [Mesa-dev] Proposal of date-based Mesa versioning for 2017
year.month or year.dayoutofdaysthatyear dayoutoofdaysthatyear skips lots of integers quickly: reducing confusion of where is release x.(y - something) and better handles quick fix releases but makes it harder to determine how far into the year the release is although with some effort can be converted into an exact date On 2 October 2016 at 14:22, Tobias Klausmann wrote: > > > On 02.10.2016 13:56, Nicolai Hähnle wrote: >> >> On 01.10.2016 22:22, Tobias Klausmann wrote: >>> >>> On 01.10.2016 21:46, Marek Olšák wrote: Hi, I propose that we use versioning in the form of "year.quarter". 2017 would start with 17.0, then 17.1, 17.2, 17.3 for following quarters of the year, respectively. 2018 would start with 18.0, then 18.1, 18.2, 18.3. The motivation is that you can easily tell when a specific Mesa version was released with an accuracy of 3 months. That's the only scheme that seems practical to me. Everything else seems arbitrary or random. Opinions? >>> >>> >>> Why not just use year.month instead, would be more accurate...and >>> releases happen semi random anyway and not after a given time. >> >> >> That's fine for something like Ubuntu where they really stick to their two >> releases per year, in the same months each year. I'm not so sure that that's >> a realistic goal for Mesa, and if releases *aren't* consistently happening >> in the same months, you end up introducing a lot of confusion about which >> version numbers exist and which don't. > > > This is true, but also holds true for year.quarter, if we miss one quarterly > release (18.1, 18.2, 18.4, whoops where is 18.3). > >> >> Time-based with YY.0 for the first release of the year, and then YY.1, >> YY.2, etc. works fine. > > > Thats allright and would help in not confuse people so much, but with it you > miss the "when was it released again?" thing Marek tried to introduce. > > Greetings, > Tobias > > >> >> Cheers, >> Nicolai > > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel: fix compilation warning on gen_get_device_info
Reviewed-by: Lionel Landwerlin
On 03/10/16 07:32, Tapani Pälli wrote:
(warning: 'const' type qualifier on return type has no effect)
Signed-off-by: Tapani Pälli
---
src/intel/common/gen_device_info.c | 2 +-
src/intel/common/gen_device_info.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/intel/common/gen_device_info.c
b/src/intel/common/gen_device_info.c
index 98669b3..30df0b2 100644
--- a/src/intel/common/gen_device_info.c
+++ b/src/intel/common/gen_device_info.c
@@ -487,7 +487,7 @@ static const struct gen_device_info gen_device_info_kbl_gt4
= {
.num_slices = 3,
};
-const bool
+bool
gen_get_device_info(int devid, struct gen_device_info *devinfo)
{
switch (devid) {
diff --git a/src/intel/common/gen_device_info.h
b/src/intel/common/gen_device_info.h
index 964e429..7347db5 100644
--- a/src/intel/common/gen_device_info.h
+++ b/src/intel/common/gen_device_info.h
@@ -143,5 +143,5 @@ struct gen_device_info
/** @} */
};
-const bool gen_get_device_info(int devid, struct gen_device_info *devinfo);
+bool gen_get_device_info(int devid, struct gen_device_info *devinfo);
const char *gen_get_device_name(int devid);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 97230] MATLAB hangs if DRI3 enabled with intel driver
https://bugs.freedesktop.org/show_bug.cgi?id=97230 --- Comment #6 from sergio.calleg...@gmail.com --- Number of threads is very very large... anything that can be grepped? -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 97230] MATLAB hangs if DRI3 enabled with intel driver
https://bugs.freedesktop.org/show_bug.cgi?id=97230 --- Comment #7 from Eero Tamminen --- (In reply to sergio.callegari from comment #6) > Number of threads is very very large... anything that can be grepped? It's better to see the whole output. If the output is long, just add it as attachment instead of as comment. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Proposal of date-based Mesa versioning for 2017
On Oct 3, 2016 12:19 AM, "Albert Freeman" wrote: > > year.month or year.dayoutofdaysthatyear Why are we adding more options to an already confused discussion? > dayoutoofdaysthatyear skips lots of integers quickly: reducing > confusion of where is release x.(y - something) and better handles > quick fix releases > but makes it harder to determine how far into the year the release is > although with some effort can be converted into an exact date Quick fix releases are already handled by the stable release system which I don't think anyone is recommending we get rid of. Also, I haven't heard anyone complain that year.quarter (really, year.releaseofyear) isn't shipping enough integers. I don't see what problem your suggestion is solving. > On 2 October 2016 at 14:22, Tobias Klausmann > wrote: > > > > > > On 02.10.2016 13:56, Nicolai Hähnle wrote: > >> > >> On 01.10.2016 22:22, Tobias Klausmann wrote: > >>> > >>> On 01.10.2016 21:46, Marek Olšák wrote: > > Hi, > > I propose that we use versioning in the form of "year.quarter". > > 2017 would start with 17.0, then 17.1, 17.2, 17.3 for following > quarters of the year, respectively. > 2018 would start with 18.0, then 18.1, 18.2, 18.3. > > The motivation is that you can easily tell when a specific Mesa > version was released with an accuracy of 3 months. > > That's the only scheme that seems practical to me. Everything else > seems arbitrary or random. > > Opinions? > >>> > >>> > >>> Why not just use year.month instead, would be more accurate...and > >>> releases happen semi random anyway and not after a given time. > >> > >> > >> That's fine for something like Ubuntu where they really stick to their two > >> releases per year, in the same months each year. I'm not so sure that that's > >> a realistic goal for Mesa, and if releases *aren't* consistently happening > >> in the same months, you end up introducing a lot of confusion about which > >> version numbers exist and which don't. > > > > > > This is true, but also holds true for year.quarter, if we miss one quarterly > > release (18.1, 18.2, 18.4, whoops where is 18.3). > > > >> > >> Time-based with YY.0 for the first release of the year, and then YY.1, > >> YY.2, etc. works fine. > > > > > > Thats allright and would help in not confuse people so much, but with it you > > miss the "when was it released again?" thing Marek tried to introduce. > > > > Greetings, > > Tobias > > > > > >> > >> Cheers, > >> Nicolai > > > > > > ___ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] st/va: enable dual instances encode by sync surface
Boyuan Zhang wrote: This patch improves the performance of Vaapi Encode by enabling dual instances encoding. flush function is not called after each end_frame call. radeon/vce will do flush whenever 2 frames are submitted for encoding. Implement sync surface function to flush only if the frame hasn't been flushed yet. I filed a bug about this, pinging here as I couldn't add Boyuan to the cc on bugzilla. https://bugs.freedesktop.org/show_bug.cgi?id=98005 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3] glsl: optimize copy_propagation_elements pass
Ah now I get what you meant and these changes make sense to me, this is
easier to read. I did not spot regressions in CI run.
On 09/30/2016 06:12 PM, Ian Romanick wrote:
From: Tapani Pälli
Changes make copy_propagation_elements pass faster, reducing link
time spent in test case of bug 94477. Does not fix the actual issue
but brings down the total time. No regressions seen in CI.
v2 (idr): Formatting / whitespace fixes. Embed the acp_ref in the
acp_entry.
v3 (idr): Delete unused copy constructor. Use while(pop_head) instead
of foreach() { remove }.
Signed-off-by: Tapani Pälli
Signed-off-by: Ian Romanick
---
Ugh... I had these uncommitted changes sitting in my tree when I sent
the other patch out. Sorry for the chaos.
.../glsl/opt_copy_propagation_elements.cpp | 198 +++--
1 file changed, 148 insertions(+), 50 deletions(-)
diff --git a/src/compiler/glsl/opt_copy_propagation_elements.cpp
b/src/compiler/glsl/opt_copy_propagation_elements.cpp
index e4237cc..be89116 100644
--- a/src/compiler/glsl/opt_copy_propagation_elements.cpp
+++ b/src/compiler/glsl/opt_copy_propagation_elements.cpp
@@ -46,15 +46,32 @@
#include "ir_basic_block.h"
#include "ir_optimization.h"
#include "compiler/glsl_types.h"
+#include "util/hash_table.h"
static bool debug = false;
namespace {
+class acp_entry;
+
+/* Class that refers to acp_entry in another exec_list. Used
+ * when making removals based on rhs.
+ */
+class acp_ref : public exec_node
+{
+public:
+ acp_ref(acp_entry *e)
+ {
+ entry = e;
+ }
+ acp_entry *entry;
+};
+
class acp_entry : public exec_node
{
public:
acp_entry(ir_variable *lhs, ir_variable *rhs, int write_mask, int
swizzle[4])
+ : rhs_node(this)
{
this->lhs = lhs;
this->rhs = rhs;
@@ -62,18 +79,11 @@ public:
memcpy(this->swizzle, swizzle, sizeof(this->swizzle));
}
- acp_entry(acp_entry *a)
- {
- this->lhs = a->lhs;
- this->rhs = a->rhs;
- this->write_mask = a->write_mask;
- memcpy(this->swizzle, a->swizzle, sizeof(this->swizzle));
- }
-
ir_variable *lhs;
ir_variable *rhs;
unsigned int write_mask;
int swizzle[4];
+ acp_ref rhs_node;
};
@@ -98,14 +108,42 @@ public:
this->killed_all = false;
this->mem_ctx = ralloc_context(NULL);
this->shader_mem_ctx = NULL;
- this->acp = new(mem_ctx) exec_list;
this->kills = new(mem_ctx) exec_list;
+
+ create_acp();
}
~ir_copy_propagation_elements_visitor()
{
ralloc_free(mem_ctx);
}
+ void create_acp()
+ {
+ lhs_ht = _mesa_hash_table_create(mem_ctx, _mesa_hash_pointer,
+ _mesa_key_pointer_equal);
+ rhs_ht = _mesa_hash_table_create(mem_ctx, _mesa_hash_pointer,
+ _mesa_key_pointer_equal);
+ }
+
+ void destroy_acp()
+ {
+ _mesa_hash_table_destroy(lhs_ht, NULL);
+ _mesa_hash_table_destroy(rhs_ht, NULL);
+ }
+
+ void populate_acp(hash_table *lhs, hash_table *rhs)
+ {
+ struct hash_entry *entry;
+
+ hash_table_foreach(lhs, entry) {
+ _mesa_hash_table_insert(lhs_ht, entry->key, entry->data);
+ }
+
+ hash_table_foreach(rhs, entry) {
+ _mesa_hash_table_insert(rhs_ht, entry->key, entry->data);
+ }
+ }
+
void handle_loop(ir_loop *, bool keep_acp);
virtual ir_visitor_status visit_enter(class ir_loop *);
virtual ir_visitor_status visit_enter(class ir_function_signature *);
@@ -120,8 +158,10 @@ public:
void kill(kill_entry *k);
void handle_if_block(exec_list *instructions);
- /** List of acp_entry: The available copies to propagate */
- exec_list *acp;
+ /** Hash of acp_entry: The available copies to propagate */
+ hash_table *lhs_ht;
+ hash_table *rhs_ht;
+
/**
* List of kill_entry: The variables whose values were killed in this
* block.
@@ -147,23 +187,29 @@
ir_copy_propagation_elements_visitor::visit_enter(ir_function_signature *ir)
* block. Any instructions at global scope will be shuffled into
* main() at link time, so they're irrelevant to us.
*/
- exec_list *orig_acp = this->acp;
exec_list *orig_kills = this->kills;
bool orig_killed_all = this->killed_all;
- this->acp = new(mem_ctx) exec_list;
+ hash_table *orig_lhs_ht = lhs_ht;
+ hash_table *orig_rhs_ht = rhs_ht;
+
this->kills = new(mem_ctx) exec_list;
this->killed_all = false;
+ create_acp();
+
visit_list_elements(this, &ir->body);
- ralloc_free(this->acp);
ralloc_free(this->kills);
+ destroy_acp();
+
this->kills = orig_kills;
- this->acp = orig_acp;
this->killed_all = orig_killed_all;
+ lhs_ht = orig_lhs_ht;
+ rhs_ht = orig_rhs_ht;
+
return visit_continue_with_parent;
}
@@ -249,17 +295,19 @@
ir_copy_propagation_elements_visitor::handle_rvalue(ir_rvalue **ir)
/* Try to find ACP entries covering swizzle_chan[], hoping they're
* the same source vari
Re: [Mesa-dev] [PATCH] anv/formats: Fix build on gcc-4 and earlier
On Fri, Sep 30, 2016 at 04:11:51PM -0700, Jason Ekstrand wrote:
> I remember the first tone you fixed this but when I was going the
> ISL_SWIZZLE stuff,
Wasn't me, or at least I can't recall doing anything of the sort :)
> I couldn't find it in the git log so I went ahead and
> pushed the change. Thanks for fixing it again.
>
> Reviewed-by: Jason Ekstrand
Thanks. Pushed.
>
> On Sep 30, 2016 1:00 PM, wrote:
>
> > From: Ville Syrjälä
> >
> > gcc-4 and earlier don't allow compound literals where a constant
> > is required in -std=c99/gnu99 mode, so we can't use ISL_SWIZZLE()
> > when populating the anv_formats[] array. There are a few ways around
> > it: First one would be -std=c89/gnu89, but the rest of the code
> > depends on c99 so it's not really an option. The second option
> > would be to upgrade to gcc-5+ where the compiler behaviour was relaxed
> > a bit [1]. And the third option is just to avoid using compound
> > literals. I chose the last option since it keeps gcc-4 and earlier
> > working.
> >
> > [1] https://gcc.gnu.org/gcc-5/porting_to.html
> >
> > Cc: Jason Ekstrand
> > Cc: Topi Pohjolainen
> > Fixes: 7ddb21708c80 ("intel/isl: Add an isl_swizzle structure and use it
> > for isl_view swizzles")
> > Signed-off-by: Ville Syrjälä
> > ---
> > src/intel/vulkan/anv_formats.c | 23 +++
> > 1 file changed, 19 insertions(+), 4 deletions(-)
> >
> > diff --git a/src/intel/vulkan/anv_formats.c b/src/intel/vulkan/anv_
> > formats.c
> > index 7341d725cd0a..f6915540fb3d 100644
> > --- a/src/intel/vulkan/anv_formats.c
> > +++ b/src/intel/vulkan/anv_formats.c
> > @@ -24,9 +24,24 @@
> > #include "anv_private.h"
> > #include "vk_format_info.h"
> >
> > -#define RGBA ISL_SWIZZLE(RED, GREEN, BLUE, ALPHA)
> > -#define BGRA ISL_SWIZZLE(BLUE, GREEN, RED, ALPHA)
> > -#define RGB1 ISL_SWIZZLE(RED, GREEN, BLUE, ONE)
> > +/*
> > + * gcc-4 and earlier don't allow compound literals where a constant
> > + * is required in -std=c99/gnu99 mode, so we can't use ISL_SWIZZLE()
> > + * here. -std=c89/gnu89 would allow it, but we depend on c99 features
> > + * so using -std=c89/gnu89 is not an option. Starting from gcc-5
> > + * compound literals can also be considered constant in -std=c99/gnu99
> > + * mode.
> > + */
> > +#define _ISL_SWIZZLE(r, g, b, a) { \
> > + ISL_CHANNEL_SELECT_##r, \
> > + ISL_CHANNEL_SELECT_##g, \
> > + ISL_CHANNEL_SELECT_##b, \
> > + ISL_CHANNEL_SELECT_##a, \
> > +}
> > +
> > +#define RGBA _ISL_SWIZZLE(RED, GREEN, BLUE, ALPHA)
> > +#define BGRA _ISL_SWIZZLE(BLUE, GREEN, RED, ALPHA)
> > +#define RGB1 _ISL_SWIZZLE(RED, GREEN, BLUE, ONE)
> >
> > #define swiz_fmt(__vk_fmt, __hw_fmt, __swizzle) \
> > [__vk_fmt] = { \
> > @@ -276,7 +291,7 @@ anv_get_format(const struct gen_device_info *devinfo,
> > VkFormat vk_format,
> > format.isl_format = rgbx;
> >} else {
> > format.isl_format = isl_format_rgb_to_rgba(format.isl_format);
> > - format.swizzle = RGB1;
> > + format.swizzle = ISL_SWIZZLE(RED, GREEN, BLUE, ONE);
> >}
> > }
> >
> > --
> > 2.7.4
> >
> >
--
Ville Syrjälä
Intel OTC
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/5] st/mesa: move all sampler view code into new st_sampler_view.[ch] files
Actually, I just need to bracket some of the assertions with the test
for GL_TEXTURE_BUFFER. I'll make that change and re-test before
pushing. I suspect I did my piglit run w/ a release build on Windows.
Thanks for reviewing.
-Brian
On 10/02/2016 02:53 PM, Marek Olšák wrote:
One more fix for TBOs is needed:
diff --git a/src/mesa/state_tracker/st_sampler_view.c
b/src/mesa/state_tracker/st_sampler_view.c
index da1df86..a0bea46 100644
--- a/src/mesa/state_tracker/st_sampler_view.c
+++ b/src/mesa/state_tracker/st_sampler_view.c
@@ -459,7 +459,7 @@ st_get_texture_sampler_view_from_stobj(struct
st_context *st,
sv = st_texture_get_sampler_view(st, stObj);
- if (*sv) {
+ if (*sv && stObj->base.Target != GL_TEXTURE_BUFFER) {
/* Debug check: make sure that the sampler view's parameters are
* what they're supposed to be.
*/
If fixes this assertion failure:
arb_texture_buffer_range-ranges: state_tracker/st_sampler_view.c:472:
st_get_texture_sampler_view_from_stobj: Assertion `last_level(stObj)
== view->u.tex.last_level' failed.
Marek
On Sun, Oct 2, 2016 at 10:31 PM, Marek Olšák wrote:
FYI, the series breaks this test:
piglit/bin/glsl-resource-not-bound Buffer -auto -fbo
glsl-resource-not-bound: state_tracker/st_sampler_view.c:456:
st_get_texture_sampler_view_from_stobj: Assertion `stObj->pt' failed.
Aborted
Removing the assertion fixes it. Note that empty TBO slots are NULL.
Marek
On Sun, Oct 2, 2016 at 2:29 PM, Marek Olšák wrote:
You also need this:
diff --git a/src/mesa/state_tracker/st_vdpau.c
b/src/mesa/state_tracker/st_vdpau.c
index 4f599dd..cafbd3d 100644
--- a/src/mesa/state_tracker/st_vdpau.c
+++ b/src/mesa/state_tracker/st_vdpau.c
@@ -44,6 +44,7 @@
#include "st_vdpau.h"
#include "st_context.h"
#include "st_texture.h"
+#include "st_sampler_view.h"
#include "st_format.h"
#include "st_cb_flush.h"
With that fixed, the series is:
Reviewed-by: Marek Olšák
Marek
On Sat, Oct 1, 2016 at 12:53 AM, Brian Paul wrote:
Previously, the sampler view code was scattered across several different
files.
Note, the previous REALLOC(), FREE() for st_texture_object::sampler_views
are replaced by realloc(), free() to avoid conflicting macros in Mesa vs.
Gallium.
---
src/mesa/Makefile.sources | 2 +
src/mesa/state_tracker/st_atom_pixeltransfer.c | 1 +
src/mesa/state_tracker/st_atom_texture.c | 358 +-
src/mesa/state_tracker/st_cb_bitmap.c | 1 +
src/mesa/state_tracker/st_cb_drawpixels.c | 1 +
src/mesa/state_tracker/st_cb_eglimage.c| 2 +
src/mesa/state_tracker/st_cb_texture.c | 1 +
src/mesa/state_tracker/st_context.c| 1 +
src/mesa/state_tracker/st_sampler_view.c | 487 +
src/mesa/state_tracker/st_sampler_view.h | 83 +
src/mesa/state_tracker/st_texture.c| 93 -
src/mesa/state_tracker/st_texture.h| 34 --
12 files changed, 580 insertions(+), 484 deletions(-)
create mode 100644 src/mesa/state_tracker/st_sampler_view.c
create mode 100644 src/mesa/state_tracker/st_sampler_view.h
diff --git a/src/mesa/Makefile.sources b/src/mesa/Makefile.sources
index fbe5861..410a61a 100644
--- a/src/mesa/Makefile.sources
+++ b/src/mesa/Makefile.sources
@@ -510,6 +510,8 @@ STATETRACKER_FILES = \
state_tracker/st_pbo.h \
state_tracker/st_program.c \
state_tracker/st_program.h \
+ state_tracker/st_sampler_view.c \
+ state_tracker/st_sampler_view.h \
state_tracker/st_scissor.c \
state_tracker/st_scissor.h \
state_tracker/st_texture.c \
diff --git a/src/mesa/state_tracker/st_atom_pixeltransfer.c
b/src/mesa/state_tracker/st_atom_pixeltransfer.c
index 26d8ade..a2951a1 100644
--- a/src/mesa/state_tracker/st_atom_pixeltransfer.c
+++ b/src/mesa/state_tracker/st_atom_pixeltransfer.c
@@ -30,6 +30,7 @@
*/
#include "st_context.h"
+#include "st_sampler_view.h"
#include "st_texture.h"
#include "util/u_inlines.h"
diff --git a/src/mesa/state_tracker/st_atom_texture.c
b/src/mesa/state_tracker/st_atom_texture.c
index e5574bd..c8ae62c 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tracker/st_atom_texture.c
@@ -42,6 +42,7 @@
#include "st_context.h"
#include "st_atom.h"
+#include "st_sampler_view.h"
#include "st_texture.h"
#include "st_format.h"
#include "st_cb_texture.h"
@@ -51,363 +52,6 @@
#include "cso_cache/cso_context.h"
-/**
- * Return swizzle1(swizzle2)
- */
-static unsigned
-swizzle_swizzle(unsigned swizzle1, unsigned swizzle2)
-{
- unsigned i, swz[4];
-
- if (swizzle1 == SWIZZLE_XYZW) {
- /* identity swizzle, no change to swizzle2 */
- return swizzle2;
- }
-
- for (i = 0; i < 4; i++) {
- unsigned s = GET_SWZ(swizzle1, i);
- switch (s) {
- case SWIZZLE_X:
- case SWIZZLE_Y:
- case SWIZZLE_Z:
- case SWIZZLE_W:
- swz[i] = GET_S
Re: [Mesa-dev] [PATCH 1/2] st/va: enable dual instances encode by sync surface
Hi Andy, Thanks for the testings. Regarding to the inconsistencies, the current Vaapi dual instances encoding behaviour is random. Whether or not the dual instances is being used depends on how early the player calls sync_surface function according to the current gstreamer-vaapi's mechanism. e.g. if the player calls sync_surface too early, then we don't have enough time to receive and process the 2nd frame and we can only end up with single instance encoding for this frame as a result. And the random player behaviours depends on the current environment, for example cpufreq might be one factor. As a result, we don't guarantee the consistency especially when rate control is enabled for dual instances Vaapi encoding, since the randomness could result different calculations. For the corruption/wrong frame order issue, could you please provide more detailed information for reproduction? e.g. the clips and commands that can reproduce the issue. Does this issue only happen after enabling dual instance patch? Regards, Boyuan -Original Message- From: Andy Furniss [mailto:adf.li...@gmail.com] Sent: October-03-16 7:35 AM To: Zhang, Boyuan; mesa-dev@lists.freedesktop.org Cc: deathsim...@vodafone.de Subject: Re: [PATCH 1/2] st/va: enable dual instances encode by sync surface Boyuan Zhang wrote: > This patch improves the performance of Vaapi Encode by enabling dual > instances encoding. flush function is not called after each end_frame > call. radeon/vce will do flush whenever 2 frames are submitted for > encoding. Implement sync surface function to flush only if the frame > hasn't been flushed yet. I filed a bug about this, pinging here as I couldn't add Boyuan to the cc on bugzilla. https://bugs.freedesktop.org/show_bug.cgi?id=98005 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium/drivers: initialize pipe_resource::next to NULL
Fix potential issues if state-tracker passes in garbage in templ->next ptr. See: https://lists.freedesktop.org/archives/mesa-dev/2016-September/129867.html Signed-off-by: Rob Clark --- src/gallium/drivers/freedreno/freedreno_resource.c | 2 ++ src/gallium/drivers/i915/i915_resource_buffer.c| 1 + src/gallium/drivers/i915/i915_resource_texture.c | 2 ++ src/gallium/drivers/ilo/ilo_resource.c | 2 ++ src/gallium/drivers/llvmpipe/lp_texture.c | 2 ++ src/gallium/drivers/noop/noop_pipe.c | 1 + src/gallium/drivers/nouveau/nouveau_buffer.c | 1 + src/gallium/drivers/nouveau/nv30/nv30_miptree.c| 2 ++ src/gallium/drivers/nouveau/nv50/nv50_miptree.c| 2 ++ src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c| 1 + src/gallium/drivers/r300/r300_screen_buffer.c | 1 + src/gallium/drivers/r600/evergreen_compute.c | 1 + src/gallium/drivers/rbug/rbug_objects.c| 1 + src/gallium/drivers/softpipe/sp_texture.c | 2 ++ src/gallium/drivers/svga/svga_resource_buffer.c| 1 + src/gallium/drivers/svga/svga_resource_texture.c | 2 ++ src/gallium/drivers/swr/swr_screen.cpp | 1 + src/gallium/drivers/trace/tr_texture.c | 1 + src/gallium/drivers/vc4/vc4_resource.c | 1 + src/gallium/drivers/virgl/virgl_buffer.c | 1 + src/gallium/drivers/virgl/virgl_texture.c | 2 ++ 21 files changed, 30 insertions(+) diff --git a/src/gallium/drivers/freedreno/freedreno_resource.c b/src/gallium/drivers/freedreno/freedreno_resource.c index 1874271..2f37fae 100644 --- a/src/gallium/drivers/freedreno/freedreno_resource.c +++ b/src/gallium/drivers/freedreno/freedreno_resource.c @@ -795,6 +795,7 @@ fd_resource_create(struct pipe_screen *pscreen, return NULL; *prsc = *tmpl; + prsc->next = NULL; pipe_reference_init(&prsc->reference, 1); @@ -891,6 +892,7 @@ fd_resource_from_handle(struct pipe_screen *pscreen, return NULL; *prsc = *tmpl; + prsc->next = NULL; pipe_reference_init(&prsc->reference, 1); diff --git a/src/gallium/drivers/i915/i915_resource_buffer.c b/src/gallium/drivers/i915/i915_resource_buffer.c index 2572fc4..038b1bb 100644 --- a/src/gallium/drivers/i915/i915_resource_buffer.c +++ b/src/gallium/drivers/i915/i915_resource_buffer.c @@ -125,6 +125,7 @@ i915_buffer_create(struct pipe_screen *screen, return NULL; buf->b.b = *template; + buf->b.b.next = NULL; buf->b.vtbl = &i915_buffer_vtbl; pipe_reference_init(&buf->b.b.reference, 1); buf->b.b.screen = screen; diff --git a/src/gallium/drivers/i915/i915_resource_texture.c b/src/gallium/drivers/i915/i915_resource_texture.c index 4ade04f..a5e2f50 100644 --- a/src/gallium/drivers/i915/i915_resource_texture.c +++ b/src/gallium/drivers/i915/i915_resource_texture.c @@ -930,6 +930,7 @@ i915_texture_create(struct pipe_screen *screen, return NULL; tex->b.b = *template; + tex->b.b.next = NULL; tex->b.vtbl = &i915_texture_vtbl; pipe_reference_init(&tex->b.b.reference, 1); tex->b.b.screen = screen; @@ -1003,6 +1004,7 @@ i915_texture_from_handle(struct pipe_screen * screen, return NULL; tex->b.b = *template; + tex->b.b.next = NULL; tex->b.vtbl = &i915_texture_vtbl; pipe_reference_init(&tex->b.b.reference, 1); tex->b.b.screen = screen; diff --git a/src/gallium/drivers/ilo/ilo_resource.c b/src/gallium/drivers/ilo/ilo_resource.c index 5ca7e1b..fb294fb 100644 --- a/src/gallium/drivers/ilo/ilo_resource.c +++ b/src/gallium/drivers/ilo/ilo_resource.c @@ -555,6 +555,7 @@ tex_create(struct pipe_screen *screen, return NULL; tex->base = *templ; + tex->base.next = NULL; tex->base.screen = screen; pipe_reference_init(&tex->base.reference, 1); @@ -629,6 +630,7 @@ buf_create(struct pipe_screen *screen, const struct pipe_resource *templ) return NULL; buf->base = *templ; + buf->base.next = NULL; buf->base.screen = screen; pipe_reference_init(&buf->base.reference, 1); diff --git a/src/gallium/drivers/llvmpipe/lp_texture.c b/src/gallium/drivers/llvmpipe/lp_texture.c index 733253b..49d9c2f 100644 --- a/src/gallium/drivers/llvmpipe/lp_texture.c +++ b/src/gallium/drivers/llvmpipe/lp_texture.c @@ -247,6 +247,7 @@ llvmpipe_resource_create_front(struct pipe_screen *_screen, return NULL; lpr->base = *templat; + lpr->base.next = NULL; pipe_reference_init(&lpr->base.reference, 1); lpr->base.screen = &screen->base; @@ -448,6 +449,7 @@ llvmpipe_resource_from_handle(struct pipe_screen *screen, } lpr->base = *template; + lpr->base.next = NULL; pipe_reference_init(&lpr->base.reference, 1); lpr->base.screen = screen; diff --git a/src/gallium/drivers/noop/noop_pipe.c b/src/gallium/drivers/noop/noop_pipe.c index 3013019..0cbc370 100644 --- a/src/gallium/drivers/noop/noop_pipe.c +++ b/src/gallium/drivers/noop/noop_pipe.c @@ -107
Re: [Mesa-dev] [PATCH] gallium/drivers: initialize pipe_resource::next to NULL
I don't think that's really a good idea. Zero-initializing things is one thing, but explicitly overwrite things which were given to the driver by the st is something else. (I'm not even sure how it works if the driver always overwrites this to zero no matter what. Well I suppose those are the consequences of an interface hack.) I'd say state trackers should be fixed up and call it a day. Roland Am 03.10.2016 um 18:07 schrieb Rob Clark: > Fix potential issues if state-tracker passes in garbage in templ->next > ptr. > > See: > https://lists.freedesktop.org/archives/mesa-dev/2016-September/129867.html > > Signed-off-by: Rob Clark > --- > src/gallium/drivers/freedreno/freedreno_resource.c | 2 ++ > src/gallium/drivers/i915/i915_resource_buffer.c| 1 + > src/gallium/drivers/i915/i915_resource_texture.c | 2 ++ > src/gallium/drivers/ilo/ilo_resource.c | 2 ++ > src/gallium/drivers/llvmpipe/lp_texture.c | 2 ++ > src/gallium/drivers/noop/noop_pipe.c | 1 + > src/gallium/drivers/nouveau/nouveau_buffer.c | 1 + > src/gallium/drivers/nouveau/nv30/nv30_miptree.c| 2 ++ > src/gallium/drivers/nouveau/nv50/nv50_miptree.c| 2 ++ > src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c| 1 + > src/gallium/drivers/r300/r300_screen_buffer.c | 1 + > src/gallium/drivers/r600/evergreen_compute.c | 1 + > src/gallium/drivers/rbug/rbug_objects.c| 1 + > src/gallium/drivers/softpipe/sp_texture.c | 2 ++ > src/gallium/drivers/svga/svga_resource_buffer.c| 1 + > src/gallium/drivers/svga/svga_resource_texture.c | 2 ++ > src/gallium/drivers/swr/swr_screen.cpp | 1 + > src/gallium/drivers/trace/tr_texture.c | 1 + > src/gallium/drivers/vc4/vc4_resource.c | 1 + > src/gallium/drivers/virgl/virgl_buffer.c | 1 + > src/gallium/drivers/virgl/virgl_texture.c | 2 ++ > 21 files changed, 30 insertions(+) > > diff --git a/src/gallium/drivers/freedreno/freedreno_resource.c > b/src/gallium/drivers/freedreno/freedreno_resource.c > index 1874271..2f37fae 100644 > --- a/src/gallium/drivers/freedreno/freedreno_resource.c > +++ b/src/gallium/drivers/freedreno/freedreno_resource.c > @@ -795,6 +795,7 @@ fd_resource_create(struct pipe_screen *pscreen, > return NULL; > > *prsc = *tmpl; > + prsc->next = NULL; > > pipe_reference_init(&prsc->reference, 1); > > @@ -891,6 +892,7 @@ fd_resource_from_handle(struct pipe_screen *pscreen, > return NULL; > > *prsc = *tmpl; > + prsc->next = NULL; > > pipe_reference_init(&prsc->reference, 1); > > diff --git a/src/gallium/drivers/i915/i915_resource_buffer.c > b/src/gallium/drivers/i915/i915_resource_buffer.c > index 2572fc4..038b1bb 100644 > --- a/src/gallium/drivers/i915/i915_resource_buffer.c > +++ b/src/gallium/drivers/i915/i915_resource_buffer.c > @@ -125,6 +125,7 @@ i915_buffer_create(struct pipe_screen *screen, >return NULL; > > buf->b.b = *template; > + buf->b.b.next = NULL; > buf->b.vtbl = &i915_buffer_vtbl; > pipe_reference_init(&buf->b.b.reference, 1); > buf->b.b.screen = screen; > diff --git a/src/gallium/drivers/i915/i915_resource_texture.c > b/src/gallium/drivers/i915/i915_resource_texture.c > index 4ade04f..a5e2f50 100644 > --- a/src/gallium/drivers/i915/i915_resource_texture.c > +++ b/src/gallium/drivers/i915/i915_resource_texture.c > @@ -930,6 +930,7 @@ i915_texture_create(struct pipe_screen *screen, >return NULL; > > tex->b.b = *template; > + tex->b.b.next = NULL; > tex->b.vtbl = &i915_texture_vtbl; > pipe_reference_init(&tex->b.b.reference, 1); > tex->b.b.screen = screen; > @@ -1003,6 +1004,7 @@ i915_texture_from_handle(struct pipe_screen * screen, >return NULL; > > tex->b.b = *template; > + tex->b.b.next = NULL; > tex->b.vtbl = &i915_texture_vtbl; > pipe_reference_init(&tex->b.b.reference, 1); > tex->b.b.screen = screen; > diff --git a/src/gallium/drivers/ilo/ilo_resource.c > b/src/gallium/drivers/ilo/ilo_resource.c > index 5ca7e1b..fb294fb 100644 > --- a/src/gallium/drivers/ilo/ilo_resource.c > +++ b/src/gallium/drivers/ilo/ilo_resource.c > @@ -555,6 +555,7 @@ tex_create(struct pipe_screen *screen, >return NULL; > > tex->base = *templ; > + tex->base.next = NULL; > tex->base.screen = screen; > pipe_reference_init(&tex->base.reference, 1); > > @@ -629,6 +630,7 @@ buf_create(struct pipe_screen *screen, const struct > pipe_resource *templ) >return NULL; > > buf->base = *templ; > + buf->base.next = NULL; > buf->base.screen = screen; > pipe_reference_init(&buf->base.reference, 1); > > diff --git a/src/gallium/drivers/llvmpipe/lp_texture.c > b/src/gallium/drivers/llvmpipe/lp_texture.c > index 733253b..49d9c2f 100644 > --- a/src/gallium/drivers/llvmpipe/lp_texture.c > +++ b/src/gallium/drivers/llvmpipe/lp_texture.c > @@ -247,6 +247,7 @@ llvmp
Re: [Mesa-dev] [PATCH] autoconf: Make header install distinct for various APIs
Ping? On Sep 30, 2016 2:37 PM, "Chuck Atkins" wrote: > This fixes a problem where GL headers would only get installed if > glx was enabled. So if osmesa was enabled but not glx, then the > GL headers required by osmesa would be missing from the install. > > Signed-off-by: Chuck Atkins > --- > configure.ac| 2 ++ > src/Makefile.am | 30 ++ > src/gallium/Makefile.am | 2 ++ > src/mesa/Makefile.am| 12 ++-- > 4 files changed, 36 insertions(+), 10 deletions(-) > > diff --git a/configure.ac b/configure.ac > index 1bfac3b..c7be735 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -2641,6 +2641,8 @@ fi > AM_CONDITIONAL(HAVE_LIBDRM, test "x$have_libdrm" = xyes) > AM_CONDITIONAL(HAVE_OSMESA, test "x$enable_osmesa" = xyes) > AM_CONDITIONAL(HAVE_GALLIUM_OSMESA, test "x$enable_gallium_osmesa" = > xyes) > +AM_CONDITIONAL(HAVE_COMMON_OSMESA, test "x$enable_osmesa" = xyes -o \ > +"x$enable_gallium_osmesa" = xyes) > > AM_CONDITIONAL(HAVE_X86_ASM, test "x$asm_arch" = xx86 -o "x$asm_arch" = > xx86_64) > AM_CONDITIONAL(HAVE_X86_64_ASM, test "x$asm_arch" = xx86_64) > diff --git a/src/Makefile.am b/src/Makefile.am > index 551f431..c04ee1b 100644 > --- a/src/Makefile.am > +++ b/src/Makefile.am > @@ -47,6 +47,36 @@ CLEANFILES = $(BUILT_SOURCES) > > SUBDIRS = . gtest util mapi/glapi/gen mapi > > +if HAVE_OPENGL > +gldir = $(includedir)/GL > +gl_HEADERS = \ > + $(top_srcdir)/include/GL/gl.h \ > + $(top_srcdir)/include/GL/glext.h \ > + $(top_srcdir)/include/GL/glcorearb.h \ > + $(top_srcdir)/include/GL/gl_mangle.h > +endif > + > +if HAVE_GLX > +glxdir = $(includedir)/GL > +glx_HEADERS = \ > + $(top_srcdir)/include/GL/glx.h \ > + $(top_srcdir)/include/GL/glxext.h \ > + $(top_srcdir)/include/GL/glx_mangle.h \ > + $(top_srcdir)/include/GL/mesa_glinterop.h > +pkgconfigdir = $(libdir)/pkgconfig > +pkgconfig_DATA = mesa/gl.pc > +else > +if HAVE_EGL > +eglinteropdir = $(includedir)/GL > +eglinterop_HEADERS = $(top_srcdir)/include/GL/mesa_glinterop.h > +endif > +endif > + > +if HAVE_COMMON_OSMESA > +osmesadir = $(includedir)/GL > +osmesa_HEADERS = $(top_srcdir)/include/GL/osmesa.h > +endif > + > # include only conditionally ? > SUBDIRS += compiler > > diff --git a/src/gallium/Makefile.am b/src/gallium/Makefile.am > index 34671ca..caf5fd8 100644 > --- a/src/gallium/Makefile.am > +++ b/src/gallium/Makefile.am > @@ -148,6 +148,8 @@ endif > > if HAVE_GALLIUM_OSMESA > SUBDIRS += state_trackers/osmesa targets/osmesa > +osmesadir = $(includedir)/GL > +osmesa_HEADERS = $(top_srcdir)/include/GL/osmesa.h > endif > > if HAVE_ST_VA > diff --git a/src/mesa/Makefile.am b/src/mesa/Makefile.am > index 037384a..22db400 100644 > --- a/src/mesa/Makefile.am > +++ b/src/mesa/Makefile.am > @@ -31,11 +31,8 @@ endif > > if HAVE_OSMESA > SUBDIRS += drivers/osmesa > -endif > - > -if HAVE_GLX > -gldir = $(includedir)/GL > -gl_HEADERS = $(top_srcdir)/include/GL/*.h > +osmesadir = $(includedir)/GL > +osmesa_HEADERS = $(top_srcdir)/include/GL/osmesa.h > endif > > include Makefile.sources > @@ -161,11 +158,6 @@ libmesa_sse41_la_SOURCES = \ > > libmesa_sse41_la_CFLAGS = $(AM_CFLAGS) $(SSE41_CFLAGS) > > -if HAVE_GLX > -pkgconfigdir = $(libdir)/pkgconfig > -pkgconfig_DATA = gl.pc > -endif > - > MKDIR_GEN = $(AM_V_at)$(MKDIR_P) $(@D) > YACC_GEN = $(AM_V_GEN)$(YACC) $(YFLAGS) > LEX_GEN = $(AM_V_GEN)$(LEX) $(LFLAGS) > -- > 2.7.4 > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/9] anv/gen8_pipeline: Use Alternate floating point mode when use_alt_mode is set in prog_data
On Sun, Oct 2, 2016 at 1:59 PM, Kenneth Graunke wrote: > On Friday, September 30, 2016 3:33:12 PM PDT Anuj Phogat wrote: >> Signed-off-by: Anuj Phogat >> --- >> src/intel/vulkan/gen8_pipeline.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/src/intel/vulkan/gen8_pipeline.c >> b/src/intel/vulkan/gen8_pipeline.c >> index 1abb97c..7a9a3cf 100644 >> --- a/src/intel/vulkan/gen8_pipeline.c >> +++ b/src/intel/vulkan/gen8_pipeline.c >> @@ -197,7 +197,8 @@ genX(graphics_pipeline_create)( >> vs_prog_data->base.base.binding_table.size_bytes / 4; >> >> vs.ThreadDispatchPriority= false; >> - vs.FloatingPointMode = IEEE754; >> + vs.FloatingPointMode = >> vs_prog_data->base.base.use_alt_mode ? >> +Alternate : IEEE754; >> vs.IllegalOpcodeExceptionEnable = false; >> vs.AccessesUAV = false; >> vs.SoftwareExceptionEnable = false; >> > > I don't think we need this. The only reason we use ALT mode is to make > the POW opcode match the ARB_fragment_program rules for 0^0. Otherwise, > we always use IEEE-754. We should always use IEEE for SPIR-V programs. > So, adding the condition just adds a tiny bit of CPU overhead. > > How about we instead do: > >assert(!vs_prog_data->base.base.use_alt_mode); This sounds good to me. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium/drivers: initialize pipe_resource::next to NULL
the interface is a bit hand-wavey, ie. w/ things like prsc->screen overwriten by driver.. I guess I can try to track down the screen->resource_create() callers that aren't zero-init'ing the templ, although the # of callers seemed much higher than # of drivers BR, -R On Mon, Oct 3, 2016 at 12:27 PM, Roland Scheidegger wrote: > I don't think that's really a good idea. Zero-initializing things is one > thing, but explicitly overwrite things which were given to the driver by > the st is something else. > (I'm not even sure how it works if the driver always overwrites this to > zero no matter what. Well I suppose those are the consequences of an > interface hack.) > > I'd say state trackers should be fixed up and call it a day. > > Roland > > > Am 03.10.2016 um 18:07 schrieb Rob Clark: >> Fix potential issues if state-tracker passes in garbage in templ->next >> ptr. >> >> See: >> https://lists.freedesktop.org/archives/mesa-dev/2016-September/129867.html >> >> Signed-off-by: Rob Clark >> --- >> src/gallium/drivers/freedreno/freedreno_resource.c | 2 ++ >> src/gallium/drivers/i915/i915_resource_buffer.c| 1 + >> src/gallium/drivers/i915/i915_resource_texture.c | 2 ++ >> src/gallium/drivers/ilo/ilo_resource.c | 2 ++ >> src/gallium/drivers/llvmpipe/lp_texture.c | 2 ++ >> src/gallium/drivers/noop/noop_pipe.c | 1 + >> src/gallium/drivers/nouveau/nouveau_buffer.c | 1 + >> src/gallium/drivers/nouveau/nv30/nv30_miptree.c| 2 ++ >> src/gallium/drivers/nouveau/nv50/nv50_miptree.c| 2 ++ >> src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c| 1 + >> src/gallium/drivers/r300/r300_screen_buffer.c | 1 + >> src/gallium/drivers/r600/evergreen_compute.c | 1 + >> src/gallium/drivers/rbug/rbug_objects.c| 1 + >> src/gallium/drivers/softpipe/sp_texture.c | 2 ++ >> src/gallium/drivers/svga/svga_resource_buffer.c| 1 + >> src/gallium/drivers/svga/svga_resource_texture.c | 2 ++ >> src/gallium/drivers/swr/swr_screen.cpp | 1 + >> src/gallium/drivers/trace/tr_texture.c | 1 + >> src/gallium/drivers/vc4/vc4_resource.c | 1 + >> src/gallium/drivers/virgl/virgl_buffer.c | 1 + >> src/gallium/drivers/virgl/virgl_texture.c | 2 ++ >> 21 files changed, 30 insertions(+) >> >> diff --git a/src/gallium/drivers/freedreno/freedreno_resource.c >> b/src/gallium/drivers/freedreno/freedreno_resource.c >> index 1874271..2f37fae 100644 >> --- a/src/gallium/drivers/freedreno/freedreno_resource.c >> +++ b/src/gallium/drivers/freedreno/freedreno_resource.c >> @@ -795,6 +795,7 @@ fd_resource_create(struct pipe_screen *pscreen, >> return NULL; >> >> *prsc = *tmpl; >> + prsc->next = NULL; >> >> pipe_reference_init(&prsc->reference, 1); >> >> @@ -891,6 +892,7 @@ fd_resource_from_handle(struct pipe_screen *pscreen, >> return NULL; >> >> *prsc = *tmpl; >> + prsc->next = NULL; >> >> pipe_reference_init(&prsc->reference, 1); >> >> diff --git a/src/gallium/drivers/i915/i915_resource_buffer.c >> b/src/gallium/drivers/i915/i915_resource_buffer.c >> index 2572fc4..038b1bb 100644 >> --- a/src/gallium/drivers/i915/i915_resource_buffer.c >> +++ b/src/gallium/drivers/i915/i915_resource_buffer.c >> @@ -125,6 +125,7 @@ i915_buffer_create(struct pipe_screen *screen, >>return NULL; >> >> buf->b.b = *template; >> + buf->b.b.next = NULL; >> buf->b.vtbl = &i915_buffer_vtbl; >> pipe_reference_init(&buf->b.b.reference, 1); >> buf->b.b.screen = screen; >> diff --git a/src/gallium/drivers/i915/i915_resource_texture.c >> b/src/gallium/drivers/i915/i915_resource_texture.c >> index 4ade04f..a5e2f50 100644 >> --- a/src/gallium/drivers/i915/i915_resource_texture.c >> +++ b/src/gallium/drivers/i915/i915_resource_texture.c >> @@ -930,6 +930,7 @@ i915_texture_create(struct pipe_screen *screen, >>return NULL; >> >> tex->b.b = *template; >> + tex->b.b.next = NULL; >> tex->b.vtbl = &i915_texture_vtbl; >> pipe_reference_init(&tex->b.b.reference, 1); >> tex->b.b.screen = screen; >> @@ -1003,6 +1004,7 @@ i915_texture_from_handle(struct pipe_screen * screen, >>return NULL; >> >> tex->b.b = *template; >> + tex->b.b.next = NULL; >> tex->b.vtbl = &i915_texture_vtbl; >> pipe_reference_init(&tex->b.b.reference, 1); >> tex->b.b.screen = screen; >> diff --git a/src/gallium/drivers/ilo/ilo_resource.c >> b/src/gallium/drivers/ilo/ilo_resource.c >> index 5ca7e1b..fb294fb 100644 >> --- a/src/gallium/drivers/ilo/ilo_resource.c >> +++ b/src/gallium/drivers/ilo/ilo_resource.c >> @@ -555,6 +555,7 @@ tex_create(struct pipe_screen *screen, >>return NULL; >> >> tex->base = *templ; >> + tex->base.next = NULL; >> tex->base.screen = screen; >> pipe_reference_init(&tex->base.reference, 1); >> >> @@ -629,6 +630,7 @@ buf_create(struct pipe_screen *screen, const struct >> pipe_resource *templ) >>
Re: [Mesa-dev] [PATCH] gallium/drivers: initialize pipe_resource::next to NULL
In an ideal world everybody would zero-intialize the template I suppose - then it would easily survive such interface changes. I thought though there shouldn't be many callers but I might have been wrong about this... Roland Am 03.10.2016 um 18:48 schrieb Rob Clark: > the interface is a bit hand-wavey, ie. w/ things like prsc->screen > overwriten by driver.. I guess I can try to track down the > screen->resource_create() callers that aren't zero-init'ing the templ, > although the # of callers seemed much higher than # of drivers > > BR, > -R > > On Mon, Oct 3, 2016 at 12:27 PM, Roland Scheidegger > wrote: >> I don't think that's really a good idea. Zero-initializing things is one >> thing, but explicitly overwrite things which were given to the driver by >> the st is something else. >> (I'm not even sure how it works if the driver always overwrites this to >> zero no matter what. Well I suppose those are the consequences of an >> interface hack.) >> >> I'd say state trackers should be fixed up and call it a day. >> >> Roland >> >> >> Am 03.10.2016 um 18:07 schrieb Rob Clark: >>> Fix potential issues if state-tracker passes in garbage in templ->next >>> ptr. >>> >>> See: >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_archives_mesa-2Ddev_2016-2DSeptember_129867.html&d=CwIBaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=xInPlWMLKJbs4ustrVugY4N6Sseh_nm5QM_qcOIvtDo&s=MBmwoG54VaoRJJdRHILG3BGMMjEABrG7shS9onVV2ns&e= >>> >>> >>> Signed-off-by: Rob Clark >>> --- >>> src/gallium/drivers/freedreno/freedreno_resource.c | 2 ++ >>> src/gallium/drivers/i915/i915_resource_buffer.c| 1 + >>> src/gallium/drivers/i915/i915_resource_texture.c | 2 ++ >>> src/gallium/drivers/ilo/ilo_resource.c | 2 ++ >>> src/gallium/drivers/llvmpipe/lp_texture.c | 2 ++ >>> src/gallium/drivers/noop/noop_pipe.c | 1 + >>> src/gallium/drivers/nouveau/nouveau_buffer.c | 1 + >>> src/gallium/drivers/nouveau/nv30/nv30_miptree.c| 2 ++ >>> src/gallium/drivers/nouveau/nv50/nv50_miptree.c| 2 ++ >>> src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c| 1 + >>> src/gallium/drivers/r300/r300_screen_buffer.c | 1 + >>> src/gallium/drivers/r600/evergreen_compute.c | 1 + >>> src/gallium/drivers/rbug/rbug_objects.c| 1 + >>> src/gallium/drivers/softpipe/sp_texture.c | 2 ++ >>> src/gallium/drivers/svga/svga_resource_buffer.c| 1 + >>> src/gallium/drivers/svga/svga_resource_texture.c | 2 ++ >>> src/gallium/drivers/swr/swr_screen.cpp | 1 + >>> src/gallium/drivers/trace/tr_texture.c | 1 + >>> src/gallium/drivers/vc4/vc4_resource.c | 1 + >>> src/gallium/drivers/virgl/virgl_buffer.c | 1 + >>> src/gallium/drivers/virgl/virgl_texture.c | 2 ++ >>> 21 files changed, 30 insertions(+) >>> >>> diff --git a/src/gallium/drivers/freedreno/freedreno_resource.c >>> b/src/gallium/drivers/freedreno/freedreno_resource.c >>> index 1874271..2f37fae 100644 >>> --- a/src/gallium/drivers/freedreno/freedreno_resource.c >>> +++ b/src/gallium/drivers/freedreno/freedreno_resource.c >>> @@ -795,6 +795,7 @@ fd_resource_create(struct pipe_screen *pscreen, >>> return NULL; >>> >>> *prsc = *tmpl; >>> + prsc->next = NULL; >>> >>> pipe_reference_init(&prsc->reference, 1); >>> >>> @@ -891,6 +892,7 @@ fd_resource_from_handle(struct pipe_screen *pscreen, >>> return NULL; >>> >>> *prsc = *tmpl; >>> + prsc->next = NULL; >>> >>> pipe_reference_init(&prsc->reference, 1); >>> >>> diff --git a/src/gallium/drivers/i915/i915_resource_buffer.c >>> b/src/gallium/drivers/i915/i915_resource_buffer.c >>> index 2572fc4..038b1bb 100644 >>> --- a/src/gallium/drivers/i915/i915_resource_buffer.c >>> +++ b/src/gallium/drivers/i915/i915_resource_buffer.c >>> @@ -125,6 +125,7 @@ i915_buffer_create(struct pipe_screen *screen, >>>return NULL; >>> >>> buf->b.b = *template; >>> + buf->b.b.next = NULL; >>> buf->b.vtbl = &i915_buffer_vtbl; >>> pipe_reference_init(&buf->b.b.reference, 1); >>> buf->b.b.screen = screen; >>> diff --git a/src/gallium/drivers/i915/i915_resource_texture.c >>> b/src/gallium/drivers/i915/i915_resource_texture.c >>> index 4ade04f..a5e2f50 100644 >>> --- a/src/gallium/drivers/i915/i915_resource_texture.c >>> +++ b/src/gallium/drivers/i915/i915_resource_texture.c >>> @@ -930,6 +930,7 @@ i915_texture_create(struct pipe_screen *screen, >>>return NULL; >>> >>> tex->b.b = *template; >>> + tex->b.b.next = NULL; >>> tex->b.vtbl = &i915_texture_vtbl; >>> pipe_reference_init(&tex->b.b.reference, 1); >>> tex->b.b.screen = screen; >>> @@ -1003,6 +1004,7 @@ i915_texture_from_handle(struct pipe_screen * screen, >>>return NULL; >>> >>> tex->b.b = *template; >>> + tex->b.b.next = NULL; >>> tex->b.vtbl = &i915_texture_vtbl; >>> pipe_ref
Re: [Mesa-dev] [PATCH] vl/dri3: fix warning about incompatible pointer type
Reviewed and Pushed. On 10/01/2016 01:22 AM, Nayan Deshmukh wrote: Signed-off-by: Nayan Deshmukh --- src/gallium/auxiliary/vl/vl_winsys_dri3.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c b/src/gallium/auxiliary/vl/vl_winsys_dri3.c index 191a64b..2929928 100644 --- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c +++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c @@ -85,7 +85,7 @@ struct vl_dri3_screen int64_t last_ust, ns_frame, last_msc, next_msc; bool flushed; - bool is_different_gpu; + int is_different_gpu; }; static void ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] nv50/ra: let simplify return an error and handle that
fixes a crash in the case simplify reports an error
Signed-off-by: Karol Herbst
---
src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
index 2d3486b..7e64f7c 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
@@ -771,7 +771,7 @@ private:
bool coalesce(ArrayList&);
bool doCoalesce(ArrayList&, unsigned int mask);
void calculateSpillWeights();
- void simplify();
+ bool simplify();
bool selectRegisters();
void cleanup(const bool success);
@@ -1305,7 +1305,7 @@ GCRA::simplifyNode(RIG_Node *node)
(node->degree < node->degreeLimit) ? "" : "(spill)");
}
-void
+bool
GCRA::simplify()
{
for (;;) {
@@ -1330,11 +1330,11 @@ GCRA::simplify()
}
if (isinf(bestScore)) {
ERROR("no viable spill candidates left\n");
-break;
+return false;
}
simplifyNode(best);
} else {
- break;
+ return true;
}
}
}
@@ -1493,7 +1493,9 @@ GCRA::allocateRegisters(ArrayList& insns)
buildRIG(insns);
calculateSpillWeights();
- simplify();
+ ret = simplify();
+ if (!ret)
+ goto out;
ret = selectRegisters();
if (!ret) {
--
2.10.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nv50/ra: let simplify return an error and handle that
Of course this only helps shader-db, right? Pretty sure you'll hit an
assert if you try to draw... Either way, that can be fixed later. This
is
Reviewed-by: Ilia Mirkin
On Mon, Oct 3, 2016 at 12:55 PM, Karol Herbst wrote:
> fixes a crash in the case simplify reports an error
>
> Signed-off-by: Karol Herbst
> ---
> src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
> index 2d3486b..7e64f7c 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
> @@ -771,7 +771,7 @@ private:
> bool coalesce(ArrayList&);
> bool doCoalesce(ArrayList&, unsigned int mask);
> void calculateSpillWeights();
> - void simplify();
> + bool simplify();
> bool selectRegisters();
> void cleanup(const bool success);
>
> @@ -1305,7 +1305,7 @@ GCRA::simplifyNode(RIG_Node *node)
> (node->degree < node->degreeLimit) ? "" : "(spill)");
> }
>
> -void
> +bool
> GCRA::simplify()
> {
> for (;;) {
> @@ -1330,11 +1330,11 @@ GCRA::simplify()
> }
> if (isinf(bestScore)) {
> ERROR("no viable spill candidates left\n");
> -break;
> +return false;
> }
> simplifyNode(best);
>} else {
> - break;
> + return true;
>}
> }
> }
> @@ -1493,7 +1493,9 @@ GCRA::allocateRegisters(ArrayList& insns)
>
> buildRIG(insns);
> calculateSpillWeights();
> - simplify();
> + ret = simplify();
> + if (!ret)
> + goto out;
>
> ret = selectRegisters();
> if (!ret) {
> --
> 2.10.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] autoconf: Make header install distinct for various APIs
On 30 September 2016 at 19:37, Chuck Atkins wrote:
> This fixes a problem where GL headers would only get installed if
> glx was enabled. So if osmesa was enabled but not glx, then the
> GL headers required by osmesa would be missing from the install.
>
> Signed-off-by: Chuck Atkins
> ---
> configure.ac| 2 ++
> src/Makefile.am | 30 ++
> src/gallium/Makefile.am | 2 ++
> src/mesa/Makefile.am| 12 ++--
> 4 files changed, 36 insertions(+), 10 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 1bfac3b..c7be735 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -2641,6 +2641,8 @@ fi
> AM_CONDITIONAL(HAVE_LIBDRM, test "x$have_libdrm" = xyes)
> AM_CONDITIONAL(HAVE_OSMESA, test "x$enable_osmesa" = xyes)
> AM_CONDITIONAL(HAVE_GALLIUM_OSMESA, test "x$enable_gallium_osmesa" = xyes)
> +AM_CONDITIONAL(HAVE_COMMON_OSMESA, test "x$enable_osmesa" = xyes -o \
> +"x$enable_gallium_osmesa" = xyes)
>
Maybe we won't need this hunk, see below.
> AM_CONDITIONAL(HAVE_X86_ASM, test "x$asm_arch" = xx86 -o "x$asm_arch" =
> xx86_64)
> AM_CONDITIONAL(HAVE_X86_64_ASM, test "x$asm_arch" = xx86_64)
> diff --git a/src/Makefile.am b/src/Makefile.am
> index 551f431..c04ee1b 100644
> --- a/src/Makefile.am
> +++ b/src/Makefile.am
> @@ -47,6 +47,36 @@ CLEANFILES = $(BUILT_SOURCES)
>
> SUBDIRS = . gtest util mapi/glapi/gen mapi
>
> +if HAVE_OPENGL
> +gldir = $(includedir)/GL
> +gl_HEADERS = \
> + $(top_srcdir)/include/GL/gl.h \
> + $(top_srcdir)/include/GL/glext.h \
> + $(top_srcdir)/include/GL/glcorearb.h \
> + $(top_srcdir)/include/GL/gl_mangle.h
> +endif
> +
> +if HAVE_GLX
> +glxdir = $(includedir)/GL
> +glx_HEADERS = \
> + $(top_srcdir)/include/GL/glx.h \
> + $(top_srcdir)/include/GL/glxext.h \
> + $(top_srcdir)/include/GL/glx_mangle.h \
> + $(top_srcdir)/include/GL/mesa_glinterop.h
> +pkgconfigdir = $(libdir)/pkgconfig
> +pkgconfig_DATA = mesa/gl.pc
> +else
> +if HAVE_EGL
> +eglinteropdir = $(includedir)/GL
> +eglinterop_HEADERS = $(top_srcdir)/include/GL/mesa_glinterop.h
IIRC Marek was pretty clear that this header should not be installed.
Then again looking at our current wildcard installing ... seems like
it was.
Please drop this file from the install stage ?
> +endif
> +endif
> +
> +if HAVE_COMMON_OSMESA
> +osmesadir = $(includedir)/GL
> +osmesa_HEADERS = $(top_srcdir)/include/GL/osmesa.h
> +endif
> +
Why do we have this hunk, considering each target is handled explicitly ?
IMHO we should drop either this or the similar ones in
src/{mesa,gallium}/Makefile.am. The latter might be better ?
Regards,
Emil
P.S. Thank for the poke.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nv50/ra: let simplify return an error and handle that
On 10/03/2016 06:55 PM, Karol Herbst wrote:
fixes a crash in the case simplify reports an error
Signed-off-by: Karol Herbst
---
src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
index 2d3486b..7e64f7c 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
@@ -771,7 +771,7 @@ private:
bool coalesce(ArrayList&);
bool doCoalesce(ArrayList&, unsigned int mask);
void calculateSpillWeights();
- void simplify();
+ bool simplify();
bool selectRegisters();
void cleanup(const bool success);
@@ -1305,7 +1305,7 @@ GCRA::simplifyNode(RIG_Node *node)
(node->degree < node->degreeLimit) ? "" : "(spill)");
}
-void
+bool
GCRA::simplify()
{
for (;;) {
@@ -1330,11 +1330,11 @@ GCRA::simplify()
}
if (isinf(bestScore)) {
ERROR("no viable spill candidates left\n");
-break;
+return false;
}
simplifyNode(best);
} else {
- break;
+ return true;
I would suggest to move the "return true;" outside of the while(1) and
keep the break as-is, but your call (purely cosmetic).
}
}
}
@@ -1493,7 +1493,9 @@ GCRA::allocateRegisters(ArrayList& insns)
buildRIG(insns);
calculateSpillWeights();
- simplify();
+ ret = simplify();
+ if (!ret)
+ goto out;
ret = selectRegisters();
if (!ret) {
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH V2 8/9] anv/gen7_pipeline: Set sample mask field in 3DSTATE_PS
Signed-off-by: Anuj Phogat --- src/intel/vulkan/gen7_pipeline.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/intel/vulkan/gen7_pipeline.c b/src/intel/vulkan/gen7_pipeline.c index 9411631..bafee28 100644 --- a/src/intel/vulkan/gen7_pipeline.c +++ b/src/intel/vulkan/gen7_pipeline.c @@ -243,6 +243,9 @@ genX(graphics_pipeline_create)( /* Haswell requires the sample mask to be set in this packet as well as * in 3DSTATE_SAMPLE_MASK; the values should match. */ /* _NEW_BUFFERS, _NEW_MULTISAMPLE */ +#if GEN_IS_HASWELL + ps.SampleMask= 0xff; +#endif } uint32_t samples = pCreateInfo->pMultisampleState ? -- 2.5.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 9/9] anv/gen7_pipeline: Check for ksp0 when setting BarycentricInterpolationMode in 3DSTATE_WM
On Fri, Sep 30, 2016 at 5:03 PM, Jason Ekstrand wrote: > On Sep 30, 2016 3:34 PM, "Anuj Phogat" wrote: >> >> Signed-off-by: Anuj Phogat >> --- >> src/intel/vulkan/gen7_pipeline.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/src/intel/vulkan/gen7_pipeline.c >> b/src/intel/vulkan/gen7_pipeline.c >> index 4bab0bc..e804002 100644 >> --- a/src/intel/vulkan/gen7_pipeline.c >> +++ b/src/intel/vulkan/gen7_pipeline.c >> @@ -273,7 +273,8 @@ genX(graphics_pipeline_create)( >> wm.EarlyDepthStencilControl = EDSC_NORMAL; >> } >> >> - wm.BarycentricInterpolationMode= >> wm_prog_data->barycentric_interp_modes; >> + wm.BarycentricInterpolationMode= pipeline->ps_ksp0 == >> NO_KERNEL ? >> + 0 : >> wm_prog_data->barycentric_interp_modes; > > I believe this code is in a block that is already protected. True, I'll drop this patch. > >> >> wm.MultisampleRasterizationMode= samples > 1 ? >>MSRASTMODE_ON_PATTERN : >> MSRASTMODE_OFF_PIXEL; >> -- >> 2.5.5 >> >> ___ >> mesa-dev mailing list >> mesa-dev@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 8/9] anv/gen7_pipeline: Set few missing fields in 3DSTATE_PS
On Fri, Sep 30, 2016 at 5:02 PM, Jason Ekstrand wrote: > On Sep 30, 2016 3:34 PM, "Anuj Phogat" wrote: >> >> Signed-off-by: Anuj Phogat >> --- >> src/intel/vulkan/gen7_pipeline.c | 4 >> 1 file changed, 4 insertions(+) >> >> diff --git a/src/intel/vulkan/gen7_pipeline.c >> b/src/intel/vulkan/gen7_pipeline.c >> index 9411631..4bab0bc 100644 >> --- a/src/intel/vulkan/gen7_pipeline.c >> +++ b/src/intel/vulkan/gen7_pipeline.c >> @@ -243,6 +243,10 @@ genX(graphics_pipeline_create)( >> /* Haswell requires the sample mask to be set in this packet as >> well as >>* in 3DSTATE_SAMPLE_MASK; the values should match. */ >> /* _NEW_BUFFERS, _NEW_MULTISAMPLE */ >> +#if (GEN_IS_HASWELL) > > There is some code that uses this #if style but I think the "official" style > is to not indent and not use the parens. > >> + ps.SampleMask= 0xff; >> +#endif >> + ps.SamplerCount = 1; > > Of we're going to add code to set sampler count, it should be accurate. > It's probably best to drop this line and have a later patch which actually > sets it correctly. > >>} >> >>uint32_t samples = pCreateInfo->pMultisampleState ? >> -- >> 2.5.5 >> >> ___ >> mesa-dev mailing list >> mesa-dev@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev I sent out the V2: https://patchwork.freedesktop.org/patch/113460/ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2] clover: clEnqueueMigrateMemObjects
Ping On Saturday 12 September 2015 21:08:20 Serge Martin wrote: > Now that mem object can be move back to the host, I think we should latter > come with a way to optimize read mapping for such objets. For the moment if > they are mapped for reading after been moved to the host, they will be send > back to the device... > > Serge Martin (2): > clover: clEnqueueMigrateMemObjects (device) > clover: clEnqueueMigrateMemObjects (host) > > src/gallium/state_trackers/clover/api/transfer.cpp | 51 > ++ src/gallium/state_trackers/clover/core/memory.cpp | > 38 +--- src/gallium/state_trackers/clover/core/memory.hpp | 16 > +-- > .../state_trackers/clover/core/resource.cpp| 5 ++- > .../state_trackers/clover/core/resource.hpp| 3 +- > 5 files changed, 92 insertions(+), 21 deletions(-) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] anv/gen7_pipeline: Fix typo in semicolon
Signed-off-by: Anuj Phogat --- src/intel/vulkan/gen7_pipeline.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/intel/vulkan/gen7_pipeline.c b/src/intel/vulkan/gen7_pipeline.c index bafee28..c9d1f64 100644 --- a/src/intel/vulkan/gen7_pipeline.c +++ b/src/intel/vulkan/gen7_pipeline.c @@ -238,7 +238,7 @@ genX(graphics_pipeline_create)( wm_prog_data->base.dispatch_grf_start_reg, ps.DispatchGRFStartRegisterforConstantSetupData1 = 0, ps.DispatchGRFStartRegisterforConstantSetupData2 = -wm_prog_data->dispatch_grf_start_reg_2, +wm_prog_data->dispatch_grf_start_reg_2; /* Haswell requires the sample mask to be set in this packet as well as * in 3DSTATE_SAMPLE_MASK; the values should match. */ -- 2.5.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 10/30] egl/dri2: rework dri2_make_current code flow
On 25 September 2016 at 04:24, Eric Engestrom wrote:
> On Thu, Aug 25, 2016 at 05:18:32PM +0100, Emil Velikov wrote:
>> From: Emil Velikov
>>
>> Duplicate a few lines at the expense of making the code-flow clearer
>> while adding a few extra comments ;-)
>>
>> Signed-off-by: Emil Velikov
>> ---
>>
>> It makes things clearer the way on this end, but if people have better
>> suggestions I would love to hear them.
>>
>> Emil
>> ---
>> src/egl/drivers/dri2/egl_dri2.c | 43
>> ++---
>> 1 file changed, 23 insertions(+), 20 deletions(-)
>>
>> diff --git a/src/egl/drivers/dri2/egl_dri2.c
>> b/src/egl/drivers/dri2/egl_dri2.c
>> index a481236..d53c9b9 100644
>> --- a/src/egl/drivers/dri2/egl_dri2.c
>> +++ b/src/egl/drivers/dri2/egl_dri2.c
>> @@ -1248,11 +1248,12 @@ dri2_make_current(_EGLDriver *drv, _EGLDisplay
>> *disp, _EGLSurface *dsurf,
>> struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
>> struct dri2_egl_context *dri2_ctx = dri2_egl_context(ctx);
>> _EGLContext *old_ctx;
>> + _EGLDisplay *old_disp = NULL;
>> _EGLSurface *old_dsurf, *old_rsurf;
>> _EGLSurface *tmp_dsurf, *tmp_rsurf;
>> - __DRIdrawable *ddraw, *rdraw;
>> - __DRIcontext *cctx;
>> - EGLBoolean unbind;
>> + __DRIdrawable *ddraw = (dsurf) ? dri2_dpy->vtbl->get_dri_drawable(dsurf)
>> : NULL;
>> + __DRIdrawable *rdraw = (rsurf) ? dri2_dpy->vtbl->get_dri_drawable(rsurf)
>> : NULL;
>> + __DRIcontext *cctx = (dri2_ctx) ? dri2_ctx->dri_context : NULL;
>>
>> if (!dri2_dpy)
>>return _eglError(EGL_NOT_INITIALIZED, "eglMakeCurrent");
>> @@ -1263,32 +1264,34 @@ dri2_make_current(_EGLDriver *drv, _EGLDisplay
>> *disp, _EGLSurface *dsurf,
>>return EGL_FALSE;
>> }
>>
>> - /* flush before context switch */
>> - if (old_ctx)
>> - dri2_drv->glFlush();
>> -
>> - ddraw = (dsurf) ? dri2_dpy->vtbl->get_dri_drawable(dsurf) : NULL;
>> - rdraw = (rsurf) ? dri2_dpy->vtbl->get_dri_drawable(rsurf) : NULL;
>> - cctx = (dri2_ctx) ? dri2_ctx->dri_context : NULL;
>> -
>> if (old_ctx) {
>>__DRIcontext *old_cctx = dri2_egl_context(old_ctx)->dri_context;
>> +
>> + /* flush before context switch */
>> + dri2_drv->glFlush();
>>dri2_dpy->core->unbindContext(old_cctx);
>> +
>> + /* Keep track of the old dpy as we'll need it for resource cleanup */
>> + old_disp = old_ctx->Resource.Display;
>> }
>>
>> - unbind = (cctx == NULL && ddraw == NULL && rdraw == NULL);
>> +/* There's no new ctx to bind, so just destroy the old resources */
>> + if (cctx == NULL) {
>> + dri2_destroy_surface(drv, disp, old_dsurf);
>> + dri2_destroy_surface(drv, disp, old_rsurf);
>> + dri2_destroy_context(drv, disp, old_ctx);
>> + dri2_display_release(old_disp);
>>
>> - if (unbind || dri2_dpy->core->bindContext(cctx, ddraw, rdraw)) {
>> + return EGL_TRUE;
>> + }
>> + if (dri2_dpy->core->bindContext(cctx, ddraw, rdraw)) {
>
> I'm pretty sure dropping `unbind` changes the behaviour, which means
> this isn't just a refactor.
>
IIRC there was a bunch of hidden assumptions which made the "unbind"
part identical. Then again as-is it's not clear, so adding the
ddraw/rdraw check is better.
> (Also, nit: the grouping on that diff would have been better if you had
> left an empty line between the two `if` :)
>
>>dri2_destroy_surface(drv, disp, old_dsurf);
>>dri2_destroy_surface(drv, disp, old_rsurf);
>> + dri2_destroy_context(drv, disp, old_ctx);
>> + dri2_display_release(old_disp);
>
> I think `dri2_display_release()` needs to be in an `if (old_disp)` (or
> `if (old_ctx)`, they're equivalent at this point), as it will
> dereference old_disp.
>
Patch 5/30 should cover that ?
Thanks
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 10/30] egl/dri2: rework dri2_make_current code flow
From: Emil Velikov
Fold duplicate conditional blocks and add a few extra comments ;-)
v2: Bring back the explicit "unbind" logic (Eric), remove NULL derefs.
Signed-off-by: Emil Velikov
---
src/egl/drivers/dri2/egl_dri2.c | 72 -
1 file changed, 36 insertions(+), 36 deletions(-)
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 96fef52..378ee5c 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -1260,11 +1260,11 @@ dri2_make_current(_EGLDriver *drv, _EGLDisplay *disp,
_EGLSurface *dsurf,
struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
struct dri2_egl_context *dri2_ctx = dri2_egl_context(ctx);
_EGLContext *old_ctx;
+ _EGLDisplay *old_disp = NULL;
_EGLSurface *old_dsurf, *old_rsurf;
_EGLSurface *tmp_dsurf, *tmp_rsurf;
__DRIdrawable *ddraw, *rdraw;
__DRIcontext *cctx;
- EGLBoolean unbind;
if (!dri2_dpy)
return _eglError(EGL_NOT_INITIALIZED, "eglMakeCurrent");
@@ -1275,55 +1275,55 @@ dri2_make_current(_EGLDriver *drv, _EGLDisplay *disp,
_EGLSurface *dsurf,
return EGL_FALSE;
}
- /* flush before context switch */
- if (old_ctx)
- dri2_drv->glFlush();
-
ddraw = (dsurf) ? dri2_dpy->vtbl->get_dri_drawable(dsurf) : NULL;
rdraw = (rsurf) ? dri2_dpy->vtbl->get_dri_drawable(rsurf) : NULL;
cctx = (dri2_ctx) ? dri2_ctx->dri_context : NULL;
if (old_ctx) {
__DRIcontext *old_cctx = dri2_egl_context(old_ctx)->dri_context;
+
+ /* flush before context switch */
+ dri2_drv->glFlush();
dri2_dpy->core->unbindContext(old_cctx);
+
+ /* Keep track of the old dpy as we'll need it for resource cleanup */
+ old_disp = old_ctx->Resource.Display;
}
- unbind = (cctx == NULL && ddraw == NULL && rdraw == NULL);
+ /* Bind if at least one of the primitives is valid ... */
+ if (cctx || ddraw || rdraw) {
+ if (dri2_dpy->core->bindContext(cctx, ddraw, rdraw)) {
+ /* undo the previous _eglBindContext */
+ _eglBindContext(old_ctx, old_dsurf, old_rsurf, &ctx, &tmp_dsurf,
&tmp_rsurf);
+ assert(&dri2_ctx->base == ctx &&
+tmp_dsurf == dsurf &&
+tmp_rsurf == rsurf);
+
+ _eglPutSurface(dsurf);
+ _eglPutSurface(rsurf);
+ _eglPutContext(ctx);
- if (unbind || dri2_dpy->core->bindContext(cctx, ddraw, rdraw)) {
- dri2_destroy_surface(drv, disp, old_dsurf);
- dri2_destroy_surface(drv, disp, old_rsurf);
+ _eglPutSurface(old_dsurf);
+ _eglPutSurface(old_rsurf);
+ _eglPutContext(old_ctx);
- if (!unbind)
- dri2_dpy->ref_count++;
- if (old_ctx) {
- EGLDisplay old_disp = _eglGetDisplayHandle(old_ctx->Resource.Display);
- dri2_destroy_context(drv, disp, old_ctx);
- dri2_display_release(old_disp);
+ /* dri2_dpy->core->bindContext failed. We cannot tell for sure why,
but
+ * setting the error to EGL_BAD_MATCH is surely better than leaving it
+ * as EGL_SUCCESS.
+ */
+ return _eglError(EGL_BAD_MATCH, "eglMakeCurrent");
}
- return EGL_TRUE;
- } else {
- /* undo the previous _eglBindContext */
- _eglBindContext(old_ctx, old_dsurf, old_rsurf, &ctx, &tmp_dsurf,
&tmp_rsurf);
- assert(&dri2_ctx->base == ctx &&
- tmp_dsurf == dsurf &&
- tmp_rsurf == rsurf);
-
- _eglPutSurface(dsurf);
- _eglPutSurface(rsurf);
- _eglPutContext(ctx);
-
- _eglPutSurface(old_dsurf);
- _eglPutSurface(old_rsurf);
- _eglPutContext(old_ctx);
-
- /* dri2_dpy->core->bindContext failed. We cannot tell for sure why, but
- * setting the error to EGL_BAD_MATCH is surely better than leaving it
- * as EGL_SUCCESS.
- */
- return _eglError(EGL_BAD_MATCH, "eglMakeCurrent");
+ /* ... and refcount the dpy when successful. */
+ dri2_dpy->ref_count++;
}
+
+ dri2_destroy_surface(drv, disp, old_dsurf);
+ dri2_destroy_surface(drv, disp, old_rsurf);
+ dri2_destroy_context(drv, disp, old_ctx);
+ dri2_display_release(old_disp);
+
+ return EGL_TRUE;
}
__DRIdrawable *
--
2.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 97542] mesa-12.0.1 with llvm-3.9.0_rc3 - src/gallium/state_trackers/clover/llvm/invocation.cpp:212:75: error: no matching function for call to clang::CompilerInvocation::setLangDefault
https://bugs.freedesktop.org/show_bug.cgi?id=97542 --- Comment #11 from Clément Guérin --- Hello, I built mesa 12.0.3 against llvm 3.9.0 on arch linux. Rocket League and Portal were working properly, however Tomb Raider was crashing right before the Feral logo. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Request for Testing] i965: import prime buffers in the current context, not screen
On Thu, Sep 29, 2016 at 7:33 AM Martin Peres
wrote:
> On 02/09/16 10:08, Martin Peres wrote:
> >
> >
> > On 25/08/16 21:49, Kristian Høgsberg wrote:
> >> On Thu, Aug 25, 2016 at 11:38 AM, Chad Versace
> >> wrote:
> >>> On Thu 25 Aug 2016, Martin Peres wrote:
> This mirrors the codepath taken by DRI2 in IntelSetTexBuffer2() and
> fixes many applications when using DRI3:
> - Totem with libva on hw-accelerated decoding
> - obs-studio, using Window Capture (Xcomposite) as a Source
> - gstreamer with VAAPI
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71759
> Signed-off-by: Martin Peres
> ---
>
> This patch supposedly prevents gnome from running for one Arch Linux
> maintainer. Kenneth Graunke and I failed to reproduce it so I am
> asking for your help/comments on this.
>
> src/mesa/drivers/dri/i965/intel_screen.c | 24
> ++--
> 1 file changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
> b/src/mesa/drivers/dri/i965/intel_screen.c
> index 7876652..5c0d300 100644
> --- a/src/mesa/drivers/dri/i965/intel_screen.c
> +++ b/src/mesa/drivers/dri/i965/intel_screen.c
> @@ -698,8 +698,11 @@ intel_create_image_from_fds(__DRIscreen *screen,
> int *fds, int num_fds, int *strides,
> int *offsets,
> void *loaderPrivate)
> {
> + GET_CURRENT_CONTEXT(ctx);
> struct intel_screen *intelScreen = screen->driverPrivate;
> + struct brw_context *brw = brw_context(ctx);
> struct intel_image_format *f;
> + dri_bufmgr *bufmgr;
> __DRIimage *image;
> int i, index;
>
> @@ -740,8 +743,25 @@ intel_create_image_from_fds(__DRIscreen *screen,
> size = end;
> }
>
> - image->bo =
> drm_intel_bo_gem_create_from_prime(intelScreen->bufmgr,
> - fds[0], size);
> + /* Let's import the buffer into the current context instead of
> the current
> +* screen as some applications like gstreamer, totem, or obs
> create multiple
> +* X connections which end up creating multiple screens and thus
> multiple
> +* buffer managers. They then proceed to use a different X
> connection to call
> +* GLXBindTexImageExt() which should import the buffer in the
> current thread
> +* bound and not the current screen. This is done properly
> upstairs for
> +* texture management so we need to mirror this behaviour if we
> don't want
> +* the kernel rejecting our pushbuffers as the buffers have not
> been imported
> +* by the same bufmgr that sent the pushbuffer.
> +*
> +* If there is no context currently bound, then revert to using
> the screen's
> +* buffer manager and hope for the best...
> >>>
> >>> Nope. This patch breaks EGL_EXT_image_dma_buf_import.
> >>>
> >>> When the user calls eglCreateImageKHR(EGLDisplay, EGLContext, ...) with
> >>> image type EGL_LINUX_DMA_BUF_EXT, then the spec requires that context
> be
> >>> NULL. The EGLDisplay parameter determines the namespace of the newly
> >>> created
> >>> EGLImage. By design, the currently bound context (and its display) DO
> >>> NOT affect
> >>> eglCreateImage.
> >>>
> >>> Problem Example:
> >>> eglMakeCurrent(dpyA, ..., ctxA);
> >>> img = eglCreateImage(dpyB, EGL_NO_CONTEXT, ...);
> >
> > I see, that may explain the issue Ionut found with gnome. Thanks Chad!
> >
> >>
> >> The difference between DRI2 and DRI3 is that for DRI2 we'd get a
> >> DRI2Buffer back from getBuffers, and then open the flink name inside
> >> the driver with the current context's bufmgr. In the DRI3 world, we go
> >> from prime fd to drm_bo in dri3_get_pixmap_buffer() with the screen
> >> that's associated with the current drawable.
> >
> > Yes, that is the problem indeed.
> >
> >>
> >> I think the fix we're looking for is to make
> >> draw->vtable->get_dri_context() also return the __DRIscreen, then use
> >> that in dri3_get_pixmap_buffer() to get the right __DRIscreen to pass
> >> to loader_dri3_create_image().
> >
> > Seems sensible and wouldn't require changing the world! Thanks Kristian!
> > I will get to it when I come back from vacation!
>
> Hey,
>
> I am finally trying your approach but then I am not sure I understand
> what you are saying.
>
> My patch was changing the import to always happen in the currently-bound
> screen, and you said it violates the spec of EGL_EXT_image_dma_buf_import.
>
> eglCreateImage's dpy is passed all the way down to
> intel_create_image_from_fds, which is what the spec mandates.
>
The problem isn't eglCreateImage, it's when the DRI driver internally
imports a prime fd in dri3_get_pixmap_buffer()
in src/loader/loader_dri3_
[Mesa-dev] [Bug 97542] mesa-12.0.1 with llvm-3.9.0_rc3 - src/gallium/state_trackers/clover/llvm/invocation.cpp:212:75: error: no matching function for call to clang::CompilerInvocation::setLangDefault
https://bugs.freedesktop.org/show_bug.cgi?id=97542 Clément Guérin changed: What|Removed |Added CC||geecko@free.fr -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH V2 8/9] anv/gen7_pipeline: Set sample mask field in 3DSTATE_PS
Reviewed-by: Jason Ekstrand On Mon, Oct 3, 2016 at 10:13 AM, Anuj Phogat wrote: > Signed-off-by: Anuj Phogat > --- > src/intel/vulkan/gen7_pipeline.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/src/intel/vulkan/gen7_pipeline.c b/src/intel/vulkan/gen7_ > pipeline.c > index 9411631..bafee28 100644 > --- a/src/intel/vulkan/gen7_pipeline.c > +++ b/src/intel/vulkan/gen7_pipeline.c > @@ -243,6 +243,9 @@ genX(graphics_pipeline_create)( > /* Haswell requires the sample mask to be set in this packet as > well as >* in 3DSTATE_SAMPLE_MASK; the values should match. */ > /* _NEW_BUFFERS, _NEW_MULTISAMPLE */ > +#if GEN_IS_HASWELL > + ps.SampleMask= 0xff; > +#endif >} > >uint32_t samples = pCreateInfo->pMultisampleState ? > -- > 2.5.5 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 01/13] anv: Use blorp for VkCmdFillBuffer
Signed-off-by: Jason Ekstrand
---
src/intel/vulkan/anv_blorp.c | 106 +
src/intel/vulkan/anv_meta_clear.c | 120 --
2 files changed, 96 insertions(+), 130 deletions(-)
diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
index cb61070..f149f84 100644
--- a/src/intel/vulkan/anv_blorp.c
+++ b/src/intel/vulkan/anv_blorp.c
@@ -480,6 +480,20 @@ void anv_CmdBlitImage(
blorp_batch_finish(&batch);
}
+static enum isl_format
+isl_format_for_size(unsigned size_B)
+{
+ switch (size_B) {
+ case 1: return ISL_FORMAT_R8_UINT;
+ case 2: return ISL_FORMAT_R8G8_UINT;
+ case 4: return ISL_FORMAT_R8G8B8A8_UINT;
+ case 8: return ISL_FORMAT_R16G16B16A16_UINT;
+ case 16: return ISL_FORMAT_R32G32B32A32_UINT;
+ default:
+ unreachable("Not a power-of-two format size");
+ }
+}
+
static void
do_buffer_copy(struct blorp_batch *batch,
struct anv_bo *src, uint64_t src_offset,
@@ -491,16 +505,7 @@ do_buffer_copy(struct blorp_batch *batch,
/* The actual format we pick doesn't matter as blorp will throw it away.
* The only thing that actually matters is the size.
*/
- enum isl_format format;
- switch (block_size) {
- case 1: format = ISL_FORMAT_R8_UINT; break;
- case 2: format = ISL_FORMAT_R8G8_UINT;break;
- case 4: format = ISL_FORMAT_R8G8B8A8_UNORM; break;
- case 8: format = ISL_FORMAT_R16G16B16A16_UNORM; break;
- case 16: format = ISL_FORMAT_R32G32B32A32_UINT;break;
- default:
- unreachable("Not a power-of-two format size");
- }
+ enum isl_format format = isl_format_for_size(block_size);
struct isl_surf surf;
isl_surf_init(&device->isl_dev, &surf,
@@ -667,6 +672,87 @@ void anv_CmdUpdateBuffer(
blorp_batch_finish(&batch);
}
+void anv_CmdFillBuffer(
+VkCommandBuffer commandBuffer,
+VkBufferdstBuffer,
+VkDeviceSizedstOffset,
+VkDeviceSizefillSize,
+uint32_tdata)
+{
+ ANV_FROM_HANDLE(anv_cmd_buffer, cmd_buffer, commandBuffer);
+ ANV_FROM_HANDLE(anv_buffer, dst_buffer, dstBuffer);
+ struct blorp_surf surf;
+ struct isl_surf isl_surf;
+
+ struct blorp_batch batch;
+ blorp_batch_init(&cmd_buffer->device->blorp, &batch, cmd_buffer);
+
+ if (fillSize == VK_WHOLE_SIZE) {
+ fillSize = dst_buffer->size - dstOffset;
+ /* Make sure fillSize is a multiple of 4 */
+ fillSize &= ~3ull;
+ }
+
+ /* First, we compute the biggest format that can be used with the
+* given offsets and size.
+*/
+ int bs = 16;
+ bs = gcd_pow2_u64(bs, dstOffset);
+ bs = gcd_pow2_u64(bs, fillSize);
+ enum isl_format isl_format = isl_format_for_size(bs);
+
+ union isl_color_value color = {
+ .u32 = { data, data, data, data },
+ };
+
+ const uint64_t max_fill_size = MAX_SURFACE_DIM * MAX_SURFACE_DIM * bs;
+ while (fillSize >= max_fill_size) {
+ get_blorp_surf_for_anv_buffer(cmd_buffer->device,
+dst_buffer, dstOffset,
+MAX_SURFACE_DIM, MAX_SURFACE_DIM,
+MAX_SURFACE_DIM * bs, isl_format,
+&surf, &isl_surf);
+
+ blorp_clear(&batch, &surf, isl_format, ISL_SWIZZLE_IDENTITY,
+ 0, 0, 1, 0, 0, MAX_SURFACE_DIM, MAX_SURFACE_DIM,
+ color, NULL);
+ fillSize -= max_fill_size;
+ dstOffset += max_fill_size;
+ }
+
+ uint64_t height = fillSize / (MAX_SURFACE_DIM * bs);
+ assert(height < MAX_SURFACE_DIM);
+ if (height != 0) {
+ const uint64_t rect_fill_size = height * MAX_SURFACE_DIM * bs;
+ get_blorp_surf_for_anv_buffer(cmd_buffer->device,
+dst_buffer, dstOffset,
+MAX_SURFACE_DIM, height,
+MAX_SURFACE_DIM * bs, isl_format,
+&surf, &isl_surf);
+
+ blorp_clear(&batch, &surf, isl_format, ISL_SWIZZLE_IDENTITY,
+ 0, 0, 1, 0, 0, MAX_SURFACE_DIM, height,
+ color, NULL);
+ fillSize -= rect_fill_size;
+ dstOffset += rect_fill_size;
+ }
+
+ if (fillSize != 0) {
+ const uint32_t width = fillSize / bs;
+ get_blorp_surf_for_anv_buffer(cmd_buffer->device,
+dst_buffer, dstOffset,
+width, 1,
+width * bs, isl_format,
+&surf, &isl_surf);
+
+ blorp_clear(&batch, &surf, isl_format, ISL_SWIZZLE_IDENTITY,
+ 0, 0, 1, 0, 0, width, 1,
+ color, NULL);
+ }
+
+ blorp_batch_finish(&batch);
+}
+
void anv_CmdClearColorImage(
VkCommandBuffer
Re: [Mesa-dev] [PATCH] anv/gen7_pipeline: Fix typo in semicolon
Reviewed-by: Jason Ekstrand On Mon, Oct 3, 2016 at 10:44 AM, Anuj Phogat wrote: > Signed-off-by: Anuj Phogat > --- > src/intel/vulkan/gen7_pipeline.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/intel/vulkan/gen7_pipeline.c b/src/intel/vulkan/gen7_ > pipeline.c > index bafee28..c9d1f64 100644 > --- a/src/intel/vulkan/gen7_pipeline.c > +++ b/src/intel/vulkan/gen7_pipeline.c > @@ -238,7 +238,7 @@ genX(graphics_pipeline_create)( > wm_prog_data->base.dispatch_grf_start_reg, > ps.DispatchGRFStartRegisterforConstantSetupData1 = 0, > ps.DispatchGRFStartRegisterforConstantSetupData2 = > -wm_prog_data->dispatch_grf_start_reg_2, > +wm_prog_data->dispatch_grf_start_reg_2; > > /* Haswell requires the sample mask to be set in this packet as > well as >* in 3DSTATE_SAMPLE_MASK; the values should match. */ > -- > 2.5.5 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] st/va: enable dual instances encode by sync surface
Zhang, Boyuan wrote: Hi Andy, Thanks for the testings. Regarding to the inconsistencies, the current Vaapi dual instances encoding behaviour is random. Whether or not the dual instances is being used depends on how early the player calls sync_surface function according to the current gstreamer-vaapi's mechanism. e.g. if the player calls sync_surface too early, then we don't have enough time to receive and process the 2nd frame and we can only end up with single instance encoding for this frame as a result. And the random player behaviours depends on the current environment, for example cpufreq might be one factor. As a result, we don't guarantee the consistency especially when rate control is enabled for dual instances Vaapi encoding, since the randomness could result different calculations. OK, I guess OMX is less dependent on player, because I can't reproduce with that and speed suggests I get dual instance. So far I can only get the low bitrate files with vbr. cbr always at least seems to come out the correct size. cpq is also affected by the issue = different md5sums and sometimes out of order. For the corruption/wrong frame order issue, could you please provide more detailed information for reproduction? e.g. the clips and commands that can reproduce the issue. Does this issue only happen after enabling dual instance patch? The corruption I mentioned was due to low bitrate sometimes for vbr. The out of order seems quite easy to produce with 1080p input. I tend to use raw video, but transcoding can also reproduce (just I prefer raw as at least I know it's the enc rather that the dec). Resetting mesa onto this commit (+applying patch 2 and later fix patch + firmware patch) reproduces the issue. I also previously tested last firmware (md5sum only) and it had the issue. Resetting mesa on the commit before or just disabling dual instance on head does not have the issue. The exact command for this test was - for x in $(seq 1 20); do gst-launch-1.0 -f filesrc location=/mnt/ramdisk/raw-1000f-1080p.nv12 blocksize=3110400 ! video/x-raw,format=NV12,width=1920,height=1080,framerate=50/1 ! queue ! vaapih264enc ! video/x-h264, profile=baseline ! filesink location=/mnt/ramdisk/out-$x.264; done Not all of these will have the reversal and the 5fd5c match single inst but here's a bad one out of this run reversal and some corruption. out-2.264 - https://drive.google.com/file/d/0BxP5-S1t9VEENjFkME1WTktiSUE/view?usp=sharing md5sum /mnt/ramdisk/out-* 80430ea3dc361dd9fe57a8c7746b /mnt/ramdisk/out-10.264 a68f7218e81a6cdf9f3d20eaaf57a48a /mnt/ramdisk/out-11.264 68d6de4f53f73c72f48f42a08b56a78b /mnt/ramdisk/out-12.264 5fd5c5496a26e13158e31fbdb3c68e7b /mnt/ramdisk/out-1.264 6be1f7bcea99194f59d7feaf827fe4e2 /mnt/ramdisk/out-13.264 d8a184f149f59ab308f0deec9bc9f53c /mnt/ramdisk/out-14.264 5fd5c5496a26e13158e31fbdb3c68e7b /mnt/ramdisk/out-15.264 4a4b2dbeef4a6ef2e6327b455f7c8b87 /mnt/ramdisk/out-16.264 5fd5c5496a26e13158e31fbdb3c68e7b /mnt/ramdisk/out-17.264 5fd5c5496a26e13158e31fbdb3c68e7b /mnt/ramdisk/out-18.264 20f53e73ba5bc47f05531ddef7e9a849 /mnt/ramdisk/out-19.264 c1f6df236900bece57853dbec54718d1 /mnt/ramdisk/out-20.264 e61428d61ff5673dbed8f11a4c347ac7 /mnt/ramdisk/out-2.264 3106e03284b9dbf687f9a46a1c526ba7 /mnt/ramdisk/out-3.264 53c104d68ddd90e9414ca9be4dc47c40 /mnt/ramdisk/out-4.264 dae66f3dfea8edec2c6862782b007a0e /mnt/ramdisk/out-5.264 910cdc32770ce3c78e84300fa851986a /mnt/ramdisk/out-6.264 5fd5c5496a26e13158e31fbdb3c68e7b /mnt/ramdisk/out-7.264 700112ae272d52985948052efe345245 /mnt/ramdisk/out-8.264 03857eddbabfc4747cd6450d58350548 /mnt/ramdisk/out-9.264 Before dual inst md5sum /mnt/ramdisk/out-* 5fd5c5496a26e13158e31fbdb3c68e7b /mnt/ramdisk/out-10.264 5fd5c5496a26e13158e31fbdb3c68e7b /mnt/ramdisk/out-11.264 5fd5c5496a26e13158e31fbdb3c68e7b /mnt/ramdisk/out-12.264 5fd5c5496a26e13158e31fbdb3c68e7b /mnt/ramdisk/out-1.264 5fd5c5496a26e13158e31fbdb3c68e7b /mnt/ramdisk/out-13.264 5fd5c5496a26e13158e31fbdb3c68e7b /mnt/ramdisk/out-14.264 5fd5c5496a26e13158e31fbdb3c68e7b /mnt/ramdisk/out-15.264 5fd5c5496a26e13158e31fbdb3c68e7b /mnt/ramdisk/out-16.264 5fd5c5496a26e13158e31fbdb3c68e7b /mnt/ramdisk/out-17.264 5fd5c5496a26e13158e31fbdb3c68e7b /mnt/ramdisk/out-18.264 5fd5c5496a26e13158e31fbdb3c68e7b /mnt/ramdisk/out-19.264 5fd5c5496a26e13158e31fbdb3c68e7b /mnt/ramdisk/out-20.264 5fd5c5496a26e13158e31fbdb3c68e7b /mnt/ramdisk/out-2.264 5fd5c5496a26e13158e31fbdb3c68e7b /mnt/ramdisk/out-3.264 5fd5c5496a26e13158e31fbdb3c68e7b /mnt/ramdisk/out-4.264 5fd5c5496a26e13158e31fbdb3c68e7b /mnt/ramdisk/out-5.264 5fd5c5496a26e13158e31fbdb3c68e7b /mnt/ramdisk/out-6.264 5fd5c5496a26e13158e31fbdb3c68e7b /mnt/ramdisk/out-7.264 5fd5c5496a26e13158e31fbdb3c68e7b /mnt/ramdisk/out-8.264 5fd5c5496a26e13158e31fbdb3c68e7b /mnt/ramdisk/out-9.264 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/l
[Mesa-dev] [PATCH] Revert "mesa_glinterop: remove inclusion of GLX header"
This reverts commit 8472045b16b3e4621553fe451a20a9ba9f0d44b6.
Conflicts:
include/GL/mesa_glinterop.h
This patch fixes this build error with GCC 4.4.
Compiling src/glx/dri_common_interop.c ...
In file included from src/glx/dri_common_interop.c:33:
include/GL/mesa_glinterop.h:62: error: redefinition of typedef ‘GLXContext’
include/GL/glx.h:165: note: previous declaration of ‘GLXContext’ was here
Fixes: 8472045b16b3 ("mesa_glinterop: remove inclusion of GLX header")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96770
Signed-off-by: Vinson Lee
---
include/GL/mesa_glinterop.h |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/include/GL/mesa_glinterop.h b/include/GL/mesa_glinterop.h
index 383d7f9..c6a967e 100644
--- a/include/GL/mesa_glinterop.h
+++ b/include/GL/mesa_glinterop.h
@@ -52,15 +52,12 @@
#include
#include
+#include
#ifdef __cplusplus
extern "C" {
#endif
-/* Forward declarations to avoid inclusion of GL/glx.h */
-typedef struct _XDisplay Display;
-typedef struct __GLXcontextRec *GLXContext;
-
/* Forward declarations to avoid inclusion of EGL/egl.h */
typedef void *EGLDisplay;
typedef void *EGLContext;
--
1.7.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] nir: Add a nop intrinsic
On Thursday, September 15, 2016 9:16:04 PM PDT Jason Ekstrand wrote: > This intrinsic has no destination, no sources, no variables, and can be > eliminated. In other words, it does nothing and will always get deleted by > dead code elimination. However, it does provide a quick-and-easy way to > temporarily tag a particular location in a NIR shader. > > Signed-off-by: Jason Ekstrand > --- > src/compiler/nir/nir_intrinsics.h | 3 +++ > 1 file changed, 3 insertions(+) These two are: Reviewed-by: Kenneth Graunke I understand that Connor may not be a fan of this code, but it's been several weeks and we don't have a better proposal. We need to unblock RADV. I agree with Connor that we shouldn't be relying on the details of how the NIR control flow decides to split/join blocks...and inserting or removing a control flow node does tend to split/join blocks all over the place, making some set of your block pointers invalid. I like the approach of adding a nop instruction to hold the current position. The nop will end up somewhere, and you can just resume from wherever it is, and you don't have to assume anything about how NIR decided to split/join blocks. signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH V2 05/11] anv: Allocate hiz surface
On Mon, Sep 26, 2016 at 5:10 PM, Nanley Chery wrote:
> From: Chad Versace
>
> Nanley Chery:
> (rebase)
> - Use isl_surf_get_hiz_surf()
> (amend)
> - Only add a HiZ surface onto a depth/stencil attachment
> - Add comment above HiZ surface addition
> - Hide HiZ behind INTEL_VK_HIZ prior to BDW
> - Disable HiZ for untested cases
> - Remove DISABLE_AUX_BIT instead of preventing it from being added
>
> Signed-off-by: Nanley Chery
> Reviewed-by: Jason Ekstrand
> Reviewed-by: Chad Versace (v1)
>
> ---
>
> v2: Disable certain HiZ cases here (Jason)
>
> src/intel/vulkan/anv_image.c | 39 ---
> 1 file changed, 36 insertions(+), 3 deletions(-)
>
> diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
> index f6e8672..d408819 100644
> --- a/src/intel/vulkan/anv_image.c
> +++ b/src/intel/vulkan/anv_image.c
> @@ -28,6 +28,7 @@
> #include
>
> #include "anv_private.h"
> +#include "util/debug.h"
>
> #include "vk_format_info.h"
>
> @@ -60,6 +61,7 @@ choose_isl_surf_usage(VkImageUsageFlags vk_usage,
>default:
> unreachable("bad VkImageAspect");
>case VK_IMAGE_ASPECT_DEPTH_BIT:
> + isl_usage &= ~ISL_SURF_USAGE_DISABLE_AUX_BIT;
> isl_usage |= ISL_SURF_USAGE_DEPTH_BIT;
> break;
>case VK_IMAGE_ASPECT_STENCIL_BIT:
> @@ -99,6 +101,16 @@ get_surface(struct anv_image *image,
> VkImageAspectFlags aspect)
> }
> }
>
> +static void
> +add_surface(struct anv_image *image, struct anv_surface *surf)
> +{
> + assert(surf->isl.size > 0); /* isl surface must be initialized */
> +
> + surf->offset = align_u32(image->size, surf->isl.alignment);
> + image->size = surf->offset + surf->isl.size;
> + image->alignment = MAX(image->alignment, surf->isl.alignment);
> +}
> +
> /**
> * Initialize the anv_image::*_surface selected by \a aspect. Then update
> the
> * image's memory requirements (that is, the image's size and alignment).
> @@ -160,9 +172,30 @@ make_surface(const struct anv_device *dev,
> */
> assert(ok);
>
> - anv_surf->offset = align_u32(image->size, anv_surf->isl.alignment);
> - image->size = anv_surf->offset + anv_surf->isl.size;
> - image->alignment = MAX(image->alignment, anv_surf->isl.alignment);
> + add_surface(image, anv_surf);
>
In my CCS series, I split this in two and had a precursor patch that added
the add_surface helper. Do with that information what you will. I'm fine
with having it all in one patch.
> +
> + /* Allow the user to control HiZ enabling. Disable by default on gen7
> +* because resolves are not currently implemented pre-BDW.
> +*/
> + if (!env_var_as_boolean("INTEL_VK_HIZ", dev->info.gen >= 8)) {
> + anv_finishme("Implement gen7 HiZ");
> + return VK_SUCCESS;
> + } else if (vk_info->mipLevels > 1) {
> + anv_finishme("Test multi-LOD HiZ");
> + return VK_SUCCESS;
> + } else if (dev->info.gen == 8 && vk_info->samples > 1) {
> + anv_finishme("Test gen8 multisampled HiZ");
> + return VK_SUCCESS;
> + }
>
It may be better to pull this (and the usage check below) into an
image_supports_hiz helper. The early returns work for now but as soon as
we have multiple kinds of aux surfaces, we'll have to do that refactor
anyway.
> +
> + /* Add a HiZ surface to a depth buffer that will be used for rendering.
> +*/
> + if (aspect == VK_IMAGE_ASPECT_DEPTH_BIT &&
> + (image->usage & VK_IMAGE_USAGE_DEPTH_STENCIL_ATTACHMENT_BIT)) {
> + isl_surf_get_hiz_surf(&dev->isl_dev, &image->depth_surface.isl,
> +&image->hiz_surface.isl);
> + add_surface(image, &image->hiz_surface);
> + }
>
> return VK_SUCCESS;
> }
> --
> 2.10.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH V2 07/11] anv/image: Memset hiz surfaces to 0 when binding memory
Reviewed-by: Jason Ekstrand On Tue, Sep 27, 2016 at 10:59 AM, Chad Versace wrote: > On Mon 26 Sep 2016, Nanley Chery wrote: > > From: Jason Ekstrand > > > > Nanley Chery (amend): > > - Change memset value from 0xff to 0 (a defined value for HiZ). > > > > Signed-off-by: Nanley Chery > > > > --- > > > > v2. Add asserts (Jason) > > Handle NULL return value of the mmap > > Reviewed-by: Chad Versace > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] mesa: Raise INVALID_ENUM in FramebufferTexture*D for unknown textargets.
ES3-CTS.functional.negative_api.buffer.framebuffer_texture2d expects
glFramebufferTexture[123]D to raise GL_INVALID_ENUM when
supplied a completely bogus textarget parameter (i.e. 0x).
This is at odds with the spec. GLES 3.1 says:
"An INVALID_OPERATION error is generated if texture is not zero and
textarget is not one of TEXTURE_2D, TEXTURE_2D_MULTISAMPLE, or one
of the cube map face targets from table 8.21."
(and GLES 3.0 and GL 4.5 both have similar text). However, GL has a
general guideline that says:
"If a command that requires an enumerated value is passed a symbolic
constant that is not one of those specified as allowable for that
command, an INVALID_ENUM error is generated."
Apparently other vendors reconcile these two rules as follows: GL should
raise INVALID_OPERATION for actual texture target enumeration values
which are not allowed for this particular glFramebufferTexture*D call.
Any value that is not a texture target should result in GL_INVALID_ENUM.
For example, glFramebufferTexture2D with GL_TEXTURE_1D would result in
INVALID_OPERATION because it is a real texture target, but not allowed
for the 2D version of the function. But calling it with GL_FRONT would
result in INVALID_ENUM, as that isn't even a texture target.
Fixes:
- {ES3-CTS,dEQP-GLES3}.functional.negative_api.buffer.framebuffer_texture2d
-
{ES31-CTS,ES32-CTS,dEQP-GLES31}.functional.debug.negative_coverage.get_error.buffer.framebuffer_texture2d
References: https://gitlab.khronos.org/opengl/cts/merge_requests/387
Signed-off-by: Kenneth Graunke
---
src/mesa/main/fbobject.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index f8899e6..3b55e79 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -3031,8 +3031,9 @@ check_textarget(struct gl_context *ctx, int dims, GLenum
target,
err = dims != 3;
break;
default:
- err = true;
- break;
+ _mesa_error(ctx, GL_INVALID_ENUM,
+ "%s(unknown textarget 0x%x)", caller, textarget);
+ return false;
}
if (err) {
--
2.10.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] mesa: Reorganize check_textarget().
Having one top-level switch statement covering all known texture targets
will make the next change easier to implement.
Signed-off-by: Kenneth Graunke
---
src/mesa/main/fbobject.c | 80 ++--
1 file changed, 37 insertions(+), 43 deletions(-)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 09da6b7..f8899e6 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -2991,54 +2991,48 @@ check_textarget(struct gl_context *ctx, int dims,
GLenum target,
{
bool err = false;
- switch (dims) {
- case 1:
- switch (textarget) {
- case GL_TEXTURE_1D:
- break;
- case GL_TEXTURE_1D_ARRAY:
- err = !ctx->Extensions.EXT_texture_array;
- break;
- default:
- err = true;
- }
+ switch (textarget) {
+ case GL_TEXTURE_1D:
+ err = dims != 1;
break;
- case 2:
- switch (textarget) {
- case GL_TEXTURE_2D:
- break;
- case GL_TEXTURE_RECTANGLE:
- err = _mesa_is_gles(ctx)
-|| !ctx->Extensions.NV_texture_rectangle;
- break;
- case GL_TEXTURE_CUBE_MAP_POSITIVE_X:
- case GL_TEXTURE_CUBE_MAP_NEGATIVE_X:
- case GL_TEXTURE_CUBE_MAP_POSITIVE_Y:
- case GL_TEXTURE_CUBE_MAP_NEGATIVE_Y:
- case GL_TEXTURE_CUBE_MAP_POSITIVE_Z:
- case GL_TEXTURE_CUBE_MAP_NEGATIVE_Z:
- err = !ctx->Extensions.ARB_texture_cube_map;
- break;
- case GL_TEXTURE_2D_ARRAY:
- err = (_mesa_is_gles(ctx) && ctx->Version < 30)
- || !ctx->Extensions.EXT_texture_array;
- break;
- case GL_TEXTURE_2D_MULTISAMPLE:
- case GL_TEXTURE_2D_MULTISAMPLE_ARRAY:
- err = (_mesa_is_gles(ctx) ||
-!ctx->Extensions.ARB_texture_multisample) &&
- !_mesa_is_gles31(ctx);
- break;
- default:
- err = true;
- }
+ case GL_TEXTURE_1D_ARRAY:
+ err = dims != 1 || !ctx->Extensions.EXT_texture_array;
break;
- case 3:
- if (textarget != GL_TEXTURE_3D)
- err = true;
+ case GL_TEXTURE_2D:
+ err = dims != 2;
+ break;
+ case GL_TEXTURE_2D_ARRAY:
+ err = dims != 2 || !ctx->Extensions.EXT_texture_array ||
+(_mesa_is_gles(ctx) && ctx->Version < 30);
+ break;
+ case GL_TEXTURE_2D_MULTISAMPLE:
+ case GL_TEXTURE_2D_MULTISAMPLE_ARRAY:
+ err = dims != 2 ||
+!ctx->Extensions.ARB_texture_multisample ||
+(_mesa_is_gles(ctx) && ctx->Version < 31);
+ break;
+ case GL_TEXTURE_RECTANGLE:
+ err = dims != 2 || _mesa_is_gles(ctx) ||
+!ctx->Extensions.NV_texture_rectangle;
+ break;
+ case GL_TEXTURE_CUBE_MAP:
+ case GL_TEXTURE_CUBE_MAP_ARRAY:
+ err = true;
+ break;
+ case GL_TEXTURE_CUBE_MAP_POSITIVE_X:
+ case GL_TEXTURE_CUBE_MAP_NEGATIVE_X:
+ case GL_TEXTURE_CUBE_MAP_POSITIVE_Y:
+ case GL_TEXTURE_CUBE_MAP_NEGATIVE_Y:
+ case GL_TEXTURE_CUBE_MAP_POSITIVE_Z:
+ case GL_TEXTURE_CUBE_MAP_NEGATIVE_Z:
+ err = dims != 2 || !ctx->Extensions.ARB_texture_cube_map;
+ break;
+ case GL_TEXTURE_3D:
+ err = dims != 3;
break;
default:
err = true;
+ break;
}
if (err) {
--
2.10.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium/drivers: initialize pipe_resource::next to NULL
There are a lot of callers for ->resource_create() and friends.. although I suspect it is a small subset that don't zero-init. But I'll have to go through all the call sites and check, but I didn't yet find time yet to do that today.. I don't want to annoy too many folks w/ broken piglits, so if anyone is impatient I can push the current patch, and then squash a revert into a patch that fixes up the ->resource_create()/etc callers if that turns out to be the more reasonable thing.. BR, -R On Mon, Oct 3, 2016 at 12:53 PM, Roland Scheidegger wrote: > In an ideal world everybody would zero-intialize the template I suppose > - then it would easily survive such interface changes. > I thought though there shouldn't be many callers but I might have been > wrong about this... > > Roland > > > Am 03.10.2016 um 18:48 schrieb Rob Clark: >> the interface is a bit hand-wavey, ie. w/ things like prsc->screen >> overwriten by driver.. I guess I can try to track down the >> screen->resource_create() callers that aren't zero-init'ing the templ, >> although the # of callers seemed much higher than # of drivers >> >> BR, >> -R >> >> On Mon, Oct 3, 2016 at 12:27 PM, Roland Scheidegger >> wrote: >>> I don't think that's really a good idea. Zero-initializing things is one >>> thing, but explicitly overwrite things which were given to the driver by >>> the st is something else. >>> (I'm not even sure how it works if the driver always overwrites this to >>> zero no matter what. Well I suppose those are the consequences of an >>> interface hack.) >>> >>> I'd say state trackers should be fixed up and call it a day. >>> >>> Roland >>> >>> >>> Am 03.10.2016 um 18:07 schrieb Rob Clark: Fix potential issues if state-tracker passes in garbage in templ->next ptr. See: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_archives_mesa-2Ddev_2016-2DSeptember_129867.html&d=CwIBaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=xInPlWMLKJbs4ustrVugY4N6Sseh_nm5QM_qcOIvtDo&s=MBmwoG54VaoRJJdRHILG3BGMMjEABrG7shS9onVV2ns&e= Signed-off-by: Rob Clark --- src/gallium/drivers/freedreno/freedreno_resource.c | 2 ++ src/gallium/drivers/i915/i915_resource_buffer.c| 1 + src/gallium/drivers/i915/i915_resource_texture.c | 2 ++ src/gallium/drivers/ilo/ilo_resource.c | 2 ++ src/gallium/drivers/llvmpipe/lp_texture.c | 2 ++ src/gallium/drivers/noop/noop_pipe.c | 1 + src/gallium/drivers/nouveau/nouveau_buffer.c | 1 + src/gallium/drivers/nouveau/nv30/nv30_miptree.c| 2 ++ src/gallium/drivers/nouveau/nv50/nv50_miptree.c| 2 ++ src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c| 1 + src/gallium/drivers/r300/r300_screen_buffer.c | 1 + src/gallium/drivers/r600/evergreen_compute.c | 1 + src/gallium/drivers/rbug/rbug_objects.c| 1 + src/gallium/drivers/softpipe/sp_texture.c | 2 ++ src/gallium/drivers/svga/svga_resource_buffer.c| 1 + src/gallium/drivers/svga/svga_resource_texture.c | 2 ++ src/gallium/drivers/swr/swr_screen.cpp | 1 + src/gallium/drivers/trace/tr_texture.c | 1 + src/gallium/drivers/vc4/vc4_resource.c | 1 + src/gallium/drivers/virgl/virgl_buffer.c | 1 + src/gallium/drivers/virgl/virgl_texture.c | 2 ++ 21 files changed, 30 insertions(+) diff --git a/src/gallium/drivers/freedreno/freedreno_resource.c b/src/gallium/drivers/freedreno/freedreno_resource.c index 1874271..2f37fae 100644 --- a/src/gallium/drivers/freedreno/freedreno_resource.c +++ b/src/gallium/drivers/freedreno/freedreno_resource.c @@ -795,6 +795,7 @@ fd_resource_create(struct pipe_screen *pscreen, return NULL; *prsc = *tmpl; + prsc->next = NULL; pipe_reference_init(&prsc->reference, 1); @@ -891,6 +892,7 @@ fd_resource_from_handle(struct pipe_screen *pscreen, return NULL; *prsc = *tmpl; + prsc->next = NULL; pipe_reference_init(&prsc->reference, 1); diff --git a/src/gallium/drivers/i915/i915_resource_buffer.c b/src/gallium/drivers/i915/i915_resource_buffer.c index 2572fc4..038b1bb 100644 --- a/src/gallium/drivers/i915/i915_resource_buffer.c +++ b/src/gallium/drivers/i915/i915_resource_buffer.c @@ -125,6 +125,7 @@ i915_buffer_create(struct pipe_screen *screen, return NULL; buf->b.b = *template; + buf->b.b.next = NULL; buf->b.vtbl = &i915_buffer_vtbl; pipe_reference_init(&buf->b.b.reference, 1); buf->b.b.screen = screen; diff --git a/src/gallium/drivers/i915/i915_resource_texture.c b/src/gallium/drivers/i915/i915_resource_texture.c index 4
Re: [Mesa-dev] [PATCH] gallium/drivers: initialize pipe_resource::next to NULL
Sounds reasonable to me. Roland Am 04.10.2016 um 01:44 schrieb Rob Clark: > There are a lot of callers for ->resource_create() and friends.. > although I suspect it is a small subset that don't zero-init. But > I'll have to go through all the call sites and check, but I didn't yet > find time yet to do that today.. > > I don't want to annoy too many folks w/ broken piglits, so if anyone > is impatient I can push the current patch, and then squash a revert > into a patch that fixes up the ->resource_create()/etc callers if that > turns out to be the more reasonable thing.. > > BR, > -R > > On Mon, Oct 3, 2016 at 12:53 PM, Roland Scheidegger > wrote: >> In an ideal world everybody would zero-intialize the template I suppose >> - then it would easily survive such interface changes. >> I thought though there shouldn't be many callers but I might have been >> wrong about this... >> >> Roland >> >> >> Am 03.10.2016 um 18:48 schrieb Rob Clark: >>> the interface is a bit hand-wavey, ie. w/ things like prsc->screen >>> overwriten by driver.. I guess I can try to track down the >>> screen->resource_create() callers that aren't zero-init'ing the templ, >>> although the # of callers seemed much higher than # of drivers >>> >>> BR, >>> -R >>> >>> On Mon, Oct 3, 2016 at 12:27 PM, Roland Scheidegger >>> wrote: I don't think that's really a good idea. Zero-initializing things is one thing, but explicitly overwrite things which were given to the driver by the st is something else. (I'm not even sure how it works if the driver always overwrites this to zero no matter what. Well I suppose those are the consequences of an interface hack.) I'd say state trackers should be fixed up and call it a day. Roland Am 03.10.2016 um 18:07 schrieb Rob Clark: > Fix potential issues if state-tracker passes in garbage in templ->next > ptr. > > See: > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_archives_mesa-2Ddev_2016-2DSeptember_129867.html&d=CwIBaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=xInPlWMLKJbs4ustrVugY4N6Sseh_nm5QM_qcOIvtDo&s=MBmwoG54VaoRJJdRHILG3BGMMjEABrG7shS9onVV2ns&e= > > Signed-off-by: Rob Clark > --- > src/gallium/drivers/freedreno/freedreno_resource.c | 2 ++ > src/gallium/drivers/i915/i915_resource_buffer.c| 1 + > src/gallium/drivers/i915/i915_resource_texture.c | 2 ++ > src/gallium/drivers/ilo/ilo_resource.c | 2 ++ > src/gallium/drivers/llvmpipe/lp_texture.c | 2 ++ > src/gallium/drivers/noop/noop_pipe.c | 1 + > src/gallium/drivers/nouveau/nouveau_buffer.c | 1 + > src/gallium/drivers/nouveau/nv30/nv30_miptree.c| 2 ++ > src/gallium/drivers/nouveau/nv50/nv50_miptree.c| 2 ++ > src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c| 1 + > src/gallium/drivers/r300/r300_screen_buffer.c | 1 + > src/gallium/drivers/r600/evergreen_compute.c | 1 + > src/gallium/drivers/rbug/rbug_objects.c| 1 + > src/gallium/drivers/softpipe/sp_texture.c | 2 ++ > src/gallium/drivers/svga/svga_resource_buffer.c| 1 + > src/gallium/drivers/svga/svga_resource_texture.c | 2 ++ > src/gallium/drivers/swr/swr_screen.cpp | 1 + > src/gallium/drivers/trace/tr_texture.c | 1 + > src/gallium/drivers/vc4/vc4_resource.c | 1 + > src/gallium/drivers/virgl/virgl_buffer.c | 1 + > src/gallium/drivers/virgl/virgl_texture.c | 2 ++ > 21 files changed, 30 insertions(+) > > diff --git a/src/gallium/drivers/freedreno/freedreno_resource.c > b/src/gallium/drivers/freedreno/freedreno_resource.c > index 1874271..2f37fae 100644 > --- a/src/gallium/drivers/freedreno/freedreno_resource.c > +++ b/src/gallium/drivers/freedreno/freedreno_resource.c > @@ -795,6 +795,7 @@ fd_resource_create(struct pipe_screen *pscreen, > return NULL; > > *prsc = *tmpl; > + prsc->next = NULL; > > pipe_reference_init(&prsc->reference, 1); > > @@ -891,6 +892,7 @@ fd_resource_from_handle(struct pipe_screen *pscreen, > return NULL; > > *prsc = *tmpl; > + prsc->next = NULL; > > pipe_reference_init(&prsc->reference, 1); > > diff --git a/src/gallium/drivers/i915/i915_resource_buffer.c > b/src/gallium/drivers/i915/i915_resource_buffer.c > index 2572fc4..038b1bb 100644 > --- a/src/gallium/drivers/i915/i915_resource_buffer.c > +++ b/src/gallium/drivers/i915/i915_resource_buffer.c > @@ -125,6 +125,7 @@ i915_buffer_create(struct pipe_screen *screen, >return NULL; > > buf->b.b = *template; > + buf->b.b.next = NULL; > buf->b.vtbl = &i915_buffer_vtbl; > pipe_referenc
Re: [Mesa-dev] [PATCH 2/2] mesa: Raise INVALID_ENUM in FramebufferTexture*D for unknown textargets.
Both are: Reviewed-by: Timothy Arceri ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium/drivers: initialize pipe_resource::next to NULL
BTW, I think fixing this in drivers is better, because the number of resource_create implementations is limited and they are easy to find. Marek On Tue, Oct 4, 2016 at 1:45 AM, Roland Scheidegger wrote: > Sounds reasonable to me. > > Roland > > Am 04.10.2016 um 01:44 schrieb Rob Clark: >> There are a lot of callers for ->resource_create() and friends.. >> although I suspect it is a small subset that don't zero-init. But >> I'll have to go through all the call sites and check, but I didn't yet >> find time yet to do that today.. >> >> I don't want to annoy too many folks w/ broken piglits, so if anyone >> is impatient I can push the current patch, and then squash a revert >> into a patch that fixes up the ->resource_create()/etc callers if that >> turns out to be the more reasonable thing.. >> >> BR, >> -R >> >> On Mon, Oct 3, 2016 at 12:53 PM, Roland Scheidegger >> wrote: >>> In an ideal world everybody would zero-intialize the template I suppose >>> - then it would easily survive such interface changes. >>> I thought though there shouldn't be many callers but I might have been >>> wrong about this... >>> >>> Roland >>> >>> >>> Am 03.10.2016 um 18:48 schrieb Rob Clark: the interface is a bit hand-wavey, ie. w/ things like prsc->screen overwriten by driver.. I guess I can try to track down the screen->resource_create() callers that aren't zero-init'ing the templ, although the # of callers seemed much higher than # of drivers BR, -R On Mon, Oct 3, 2016 at 12:27 PM, Roland Scheidegger wrote: > I don't think that's really a good idea. Zero-initializing things is one > thing, but explicitly overwrite things which were given to the driver by > the st is something else. > (I'm not even sure how it works if the driver always overwrites this to > zero no matter what. Well I suppose those are the consequences of an > interface hack.) > > I'd say state trackers should be fixed up and call it a day. > > Roland > > > Am 03.10.2016 um 18:07 schrieb Rob Clark: >> Fix potential issues if state-tracker passes in garbage in templ->next >> ptr. >> >> See: >> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_archives_mesa-2Ddev_2016-2DSeptember_129867.html&d=CwIBaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=xInPlWMLKJbs4ustrVugY4N6Sseh_nm5QM_qcOIvtDo&s=MBmwoG54VaoRJJdRHILG3BGMMjEABrG7shS9onVV2ns&e= >> >> Signed-off-by: Rob Clark >> --- >> src/gallium/drivers/freedreno/freedreno_resource.c | 2 ++ >> src/gallium/drivers/i915/i915_resource_buffer.c| 1 + >> src/gallium/drivers/i915/i915_resource_texture.c | 2 ++ >> src/gallium/drivers/ilo/ilo_resource.c | 2 ++ >> src/gallium/drivers/llvmpipe/lp_texture.c | 2 ++ >> src/gallium/drivers/noop/noop_pipe.c | 1 + >> src/gallium/drivers/nouveau/nouveau_buffer.c | 1 + >> src/gallium/drivers/nouveau/nv30/nv30_miptree.c| 2 ++ >> src/gallium/drivers/nouveau/nv50/nv50_miptree.c| 2 ++ >> src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c| 1 + >> src/gallium/drivers/r300/r300_screen_buffer.c | 1 + >> src/gallium/drivers/r600/evergreen_compute.c | 1 + >> src/gallium/drivers/rbug/rbug_objects.c| 1 + >> src/gallium/drivers/softpipe/sp_texture.c | 2 ++ >> src/gallium/drivers/svga/svga_resource_buffer.c| 1 + >> src/gallium/drivers/svga/svga_resource_texture.c | 2 ++ >> src/gallium/drivers/swr/swr_screen.cpp | 1 + >> src/gallium/drivers/trace/tr_texture.c | 1 + >> src/gallium/drivers/vc4/vc4_resource.c | 1 + >> src/gallium/drivers/virgl/virgl_buffer.c | 1 + >> src/gallium/drivers/virgl/virgl_texture.c | 2 ++ >> 21 files changed, 30 insertions(+) >> >> diff --git a/src/gallium/drivers/freedreno/freedreno_resource.c >> b/src/gallium/drivers/freedreno/freedreno_resource.c >> index 1874271..2f37fae 100644 >> --- a/src/gallium/drivers/freedreno/freedreno_resource.c >> +++ b/src/gallium/drivers/freedreno/freedreno_resource.c >> @@ -795,6 +795,7 @@ fd_resource_create(struct pipe_screen *pscreen, >> return NULL; >> >> *prsc = *tmpl; >> + prsc->next = NULL; >> >> pipe_reference_init(&prsc->reference, 1); >> >> @@ -891,6 +892,7 @@ fd_resource_from_handle(struct pipe_screen *pscreen, >> return NULL; >> >> *prsc = *tmpl; >> + prsc->next = NULL; >> >> pipe_reference_init(&prsc->reference, 1); >> >> diff --git a/src/gallium/drivers/i915/i915_resource_buffer.c >> b/src/gallium/drivers/i915/i915_resource_buffer.c >> index 2572fc4..038b1bb 100644 >> --- a/src/gallium/drivers/i915/i915
Re: [Mesa-dev] [PATCH] gallium/drivers: initialize pipe_resource::next to NULL
I know we do at least have an etnaviv gallium driver hanging out there waiting to be merged, and don't want to cause them unnecessary rebase pain.. so if $num_of_callsites_to_fix < $num_of_gallium_drivers, I don't mind fixing it at the call sites.. but I'll have to audit a whole bunch of call-sites first to know.. BR, -R On Mon, Oct 3, 2016 at 7:55 PM, Marek Olšák wrote: > BTW, I think fixing this in drivers is better, because the number of > resource_create implementations is limited and they are easy to find. > > Marek > > On Tue, Oct 4, 2016 at 1:45 AM, Roland Scheidegger wrote: >> Sounds reasonable to me. >> >> Roland >> >> Am 04.10.2016 um 01:44 schrieb Rob Clark: >>> There are a lot of callers for ->resource_create() and friends.. >>> although I suspect it is a small subset that don't zero-init. But >>> I'll have to go through all the call sites and check, but I didn't yet >>> find time yet to do that today.. >>> >>> I don't want to annoy too many folks w/ broken piglits, so if anyone >>> is impatient I can push the current patch, and then squash a revert >>> into a patch that fixes up the ->resource_create()/etc callers if that >>> turns out to be the more reasonable thing.. >>> >>> BR, >>> -R >>> >>> On Mon, Oct 3, 2016 at 12:53 PM, Roland Scheidegger >>> wrote: In an ideal world everybody would zero-intialize the template I suppose - then it would easily survive such interface changes. I thought though there shouldn't be many callers but I might have been wrong about this... Roland Am 03.10.2016 um 18:48 schrieb Rob Clark: > the interface is a bit hand-wavey, ie. w/ things like prsc->screen > overwriten by driver.. I guess I can try to track down the > screen->resource_create() callers that aren't zero-init'ing the templ, > although the # of callers seemed much higher than # of drivers > > BR, > -R > > On Mon, Oct 3, 2016 at 12:27 PM, Roland Scheidegger > wrote: >> I don't think that's really a good idea. Zero-initializing things is one >> thing, but explicitly overwrite things which were given to the driver by >> the st is something else. >> (I'm not even sure how it works if the driver always overwrites this to >> zero no matter what. Well I suppose those are the consequences of an >> interface hack.) >> >> I'd say state trackers should be fixed up and call it a day. >> >> Roland >> >> >> Am 03.10.2016 um 18:07 schrieb Rob Clark: >>> Fix potential issues if state-tracker passes in garbage in templ->next >>> ptr. >>> >>> See: >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_archives_mesa-2Ddev_2016-2DSeptember_129867.html&d=CwIBaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=xInPlWMLKJbs4ustrVugY4N6Sseh_nm5QM_qcOIvtDo&s=MBmwoG54VaoRJJdRHILG3BGMMjEABrG7shS9onVV2ns&e= >>> >>> Signed-off-by: Rob Clark >>> --- >>> src/gallium/drivers/freedreno/freedreno_resource.c | 2 ++ >>> src/gallium/drivers/i915/i915_resource_buffer.c| 1 + >>> src/gallium/drivers/i915/i915_resource_texture.c | 2 ++ >>> src/gallium/drivers/ilo/ilo_resource.c | 2 ++ >>> src/gallium/drivers/llvmpipe/lp_texture.c | 2 ++ >>> src/gallium/drivers/noop/noop_pipe.c | 1 + >>> src/gallium/drivers/nouveau/nouveau_buffer.c | 1 + >>> src/gallium/drivers/nouveau/nv30/nv30_miptree.c| 2 ++ >>> src/gallium/drivers/nouveau/nv50/nv50_miptree.c| 2 ++ >>> src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c| 1 + >>> src/gallium/drivers/r300/r300_screen_buffer.c | 1 + >>> src/gallium/drivers/r600/evergreen_compute.c | 1 + >>> src/gallium/drivers/rbug/rbug_objects.c| 1 + >>> src/gallium/drivers/softpipe/sp_texture.c | 2 ++ >>> src/gallium/drivers/svga/svga_resource_buffer.c| 1 + >>> src/gallium/drivers/svga/svga_resource_texture.c | 2 ++ >>> src/gallium/drivers/swr/swr_screen.cpp | 1 + >>> src/gallium/drivers/trace/tr_texture.c | 1 + >>> src/gallium/drivers/vc4/vc4_resource.c | 1 + >>> src/gallium/drivers/virgl/virgl_buffer.c | 1 + >>> src/gallium/drivers/virgl/virgl_texture.c | 2 ++ >>> 21 files changed, 30 insertions(+) >>> >>> diff --git a/src/gallium/drivers/freedreno/freedreno_resource.c >>> b/src/gallium/drivers/freedreno/freedreno_resource.c >>> index 1874271..2f37fae 100644 >>> --- a/src/gallium/drivers/freedreno/freedreno_resource.c >>> +++ b/src/gallium/drivers/freedreno/freedreno_resource.c >>> @@ -795,6 +795,7 @@ fd_resource_create(struct pipe_screen *pscreen, >>> return NULL; >>> >>> *prsc = *tmpl; >>> + prsc->next = NULL; >>> >>> pipe_reference_init(&p
Re: [Mesa-dev] [PATCH] gallium/drivers: initialize pipe_resource::next to NULL
The reason I don't like this isn't really the number of callers, rather that the driver is going actively against what the state tracker told it to do. But I'm not strongly opposed to this, since effectively restricting the next field to be only valid if the resource is created externally might be a good idea on its own... Albeit zero-initializing in the state tracker has the advantage that if resource struct is going to be extended again it would work too. (Technically, there's no need that the template and the actual resource struct being the same it just makes things easier - with d3d10 in the driver interface you basically only have the templates since the drivers just return pointers to void.) Roland Am 04.10.2016 um 01:55 schrieb Marek Olšák: > BTW, I think fixing this in drivers is better, because the number of > resource_create implementations is limited and they are easy to find. > > Marek > > On Tue, Oct 4, 2016 at 1:45 AM, Roland Scheidegger wrote: >> Sounds reasonable to me. >> >> Roland >> >> Am 04.10.2016 um 01:44 schrieb Rob Clark: >>> There are a lot of callers for ->resource_create() and friends.. >>> although I suspect it is a small subset that don't zero-init. But >>> I'll have to go through all the call sites and check, but I didn't yet >>> find time yet to do that today.. >>> >>> I don't want to annoy too many folks w/ broken piglits, so if anyone >>> is impatient I can push the current patch, and then squash a revert >>> into a patch that fixes up the ->resource_create()/etc callers if that >>> turns out to be the more reasonable thing.. >>> >>> BR, >>> -R >>> >>> On Mon, Oct 3, 2016 at 12:53 PM, Roland Scheidegger >>> wrote: In an ideal world everybody would zero-intialize the template I suppose - then it would easily survive such interface changes. I thought though there shouldn't be many callers but I might have been wrong about this... Roland Am 03.10.2016 um 18:48 schrieb Rob Clark: > the interface is a bit hand-wavey, ie. w/ things like prsc->screen > overwriten by driver.. I guess I can try to track down the > screen->resource_create() callers that aren't zero-init'ing the templ, > although the # of callers seemed much higher than # of drivers > > BR, > -R > > On Mon, Oct 3, 2016 at 12:27 PM, Roland Scheidegger > wrote: >> I don't think that's really a good idea. Zero-initializing things is one >> thing, but explicitly overwrite things which were given to the driver by >> the st is something else. >> (I'm not even sure how it works if the driver always overwrites this to >> zero no matter what. Well I suppose those are the consequences of an >> interface hack.) >> >> I'd say state trackers should be fixed up and call it a day. >> >> Roland >> >> >> Am 03.10.2016 um 18:07 schrieb Rob Clark: >>> Fix potential issues if state-tracker passes in garbage in templ->next >>> ptr. >>> >>> See: >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_archives_mesa-2Ddev_2016-2DSeptember_129867.html&d=CwIBaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=xInPlWMLKJbs4ustrVugY4N6Sseh_nm5QM_qcOIvtDo&s=MBmwoG54VaoRJJdRHILG3BGMMjEABrG7shS9onVV2ns&e= >>> >>> Signed-off-by: Rob Clark >>> --- >>> src/gallium/drivers/freedreno/freedreno_resource.c | 2 ++ >>> src/gallium/drivers/i915/i915_resource_buffer.c| 1 + >>> src/gallium/drivers/i915/i915_resource_texture.c | 2 ++ >>> src/gallium/drivers/ilo/ilo_resource.c | 2 ++ >>> src/gallium/drivers/llvmpipe/lp_texture.c | 2 ++ >>> src/gallium/drivers/noop/noop_pipe.c | 1 + >>> src/gallium/drivers/nouveau/nouveau_buffer.c | 1 + >>> src/gallium/drivers/nouveau/nv30/nv30_miptree.c| 2 ++ >>> src/gallium/drivers/nouveau/nv50/nv50_miptree.c| 2 ++ >>> src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c| 1 + >>> src/gallium/drivers/r300/r300_screen_buffer.c | 1 + >>> src/gallium/drivers/r600/evergreen_compute.c | 1 + >>> src/gallium/drivers/rbug/rbug_objects.c| 1 + >>> src/gallium/drivers/softpipe/sp_texture.c | 2 ++ >>> src/gallium/drivers/svga/svga_resource_buffer.c| 1 + >>> src/gallium/drivers/svga/svga_resource_texture.c | 2 ++ >>> src/gallium/drivers/swr/swr_screen.cpp | 1 + >>> src/gallium/drivers/trace/tr_texture.c | 1 + >>> src/gallium/drivers/vc4/vc4_resource.c | 1 + >>> src/gallium/drivers/virgl/virgl_buffer.c | 1 + >>> src/gallium/drivers/virgl/virgl_texture.c | 2 ++ >>> 21 files changed, 30 insertions(+) >>> >>> diff --git a/src/gallium/drivers/freedreno/freedreno_resource.c >>> b/src/gallium/drivers/freedreno/freedreno_resource.c >>>
[Mesa-dev] [PATCH 5/5] i965: fix unused variable warning in brw_emit_gpgpu_walker()
---
src/mesa/drivers/dri/i965/brw_compute.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_compute.c
b/src/mesa/drivers/dri/i965/brw_compute.c
index cde3bad..d1d39d3 100644
--- a/src/mesa/drivers/dri/i965/brw_compute.c
+++ b/src/mesa/drivers/dri/i965/brw_compute.c
@@ -116,7 +116,6 @@ static void
brw_emit_gpgpu_walker(struct brw_context *brw)
{
const struct brw_cs_prog_data *prog_data = brw->cs.prog_data;
- const struct gen_device_info *devinfo = &brw->screen->devinfo;
const GLuint *num_groups = brw->compute.num_work_groups;
uint32_t indirect_flag;
@@ -149,7 +148,7 @@ brw_emit_gpgpu_walker(struct brw_context *brw)
OUT_BATCH(0); /* Indirect Data Length */
OUT_BATCH(0); /* Indirect Data Start Address */
}
- assert(thread_width_max <= devinfo->max_cs_threads);
+ assert(thread_width_max <= brw->screen->devinfo.max_cs_threads);
OUT_BATCH(SET_FIELD(simd_size / 16, GPGPU_WALKER_SIMD_SIZE) |
SET_FIELD(thread_width_max - 1, GPGPU_WALKER_THREAD_WIDTH_MAX));
OUT_BATCH(0);/* Thread Group ID Starting X */
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/5] i965: fix unused variable warning in gen7_block_read_scratch()
---
src/mesa/drivers/dri/i965/brw_eu_emit.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c
b/src/mesa/drivers/dri/i965/brw_eu_emit.c
index c98867a..cfb3fa0 100644
--- a/src/mesa/drivers/dri/i965/brw_eu_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_eu_emit.c
@@ -2262,9 +2262,8 @@ gen7_block_read_scratch(struct brw_codegen *p,
int num_regs,
unsigned offset)
{
- const struct gen_device_info *devinfo = p->devinfo;
brw_inst *insn = next_insn(p, BRW_OPCODE_SEND);
- assert(brw_inst_pred_control(devinfo, insn) == BRW_PREDICATE_NONE);
+ assert(brw_inst_pred_control(p->devinfo, insn) == BRW_PREDICATE_NONE);
brw_set_dest(p, insn, retype(dest, BRW_REGISTER_TYPE_UW));
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/5] i965: wrap unused variable in #ifndef NDEBUG
Fixes unused variable warning in release build. --- src/mesa/drivers/dri/i965/brw_tcs.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/mesa/drivers/dri/i965/brw_tcs.c b/src/mesa/drivers/dri/i965/brw_tcs.c index 1f1b1a5..01500e0 100644 --- a/src/mesa/drivers/dri/i965/brw_tcs.c +++ b/src/mesa/drivers/dri/i965/brw_tcs.c @@ -364,9 +364,11 @@ brw_upload_tcs_prog(struct brw_context *brw) /* BRW_NEW_TESS_PROGRAMS */ struct brw_tess_ctrl_program *tcp = (struct brw_tess_ctrl_program *) brw->tess_ctrl_program; +#ifndef NDEBUG struct brw_tess_eval_program *tep = (struct brw_tess_eval_program *) brw->tess_eval_program; assert(tep); +#endif if (!brw_state_dirty(brw, _NEW_TEXTURE, -- 2.7.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/5] i965: wrap assert param in #ifndef NDEBUG
This fixes an unused variable warning on release builds.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 4
1 file changed, 4 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index dc000d9..ccf311d 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -5866,7 +5866,9 @@ fs_visitor::allocate_registers(bool allow_spilling)
schedule_instructions(SCHEDULE_POST);
if (last_scratch > 0) {
+#ifndef NDEBUG
unsigned max_scratch_size = 2 * 1024 * 1024;
+#endif
prog_data->total_scratch = brw_get_scratch_size(last_scratch);
@@ -5884,7 +5886,9 @@ fs_visitor::allocate_registers(bool allow_spilling)
* size linearly with a range of [1kB, 12kB] and 1kB granularity.
*/
prog_data->total_scratch = ALIGN(last_scratch, 1024);
+#ifndef NDEBUG
max_scratch_size = 12 * 1024;
+#endif
}
}
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/5] i965: wrap unused function in #ifndef NDEBUG
This function is only ever used by an assert() this fixes an
unused function warning in release builds.
---
src/mesa/drivers/dri/i965/gen8_draw_upload.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/gen8_draw_upload.c
b/src/mesa/drivers/dri/i965/gen8_draw_upload.c
index d2c7853..7196266 100644
--- a/src/mesa/drivers/dri/i965/gen8_draw_upload.c
+++ b/src/mesa/drivers/dri/i965/gen8_draw_upload.c
@@ -34,6 +34,7 @@
#include "intel_batchbuffer.h"
#include "intel_buffer_objects.h"
+#ifndef NDEBUG
static bool
is_passthru_format(uint32_t format)
{
@@ -47,6 +48,7 @@ is_passthru_format(uint32_t format)
return false;
}
}
+#endif
static void
gen8_emit_vertices(struct brw_context *brw)
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH V2 08/11] anv/cmd_buffer: Add code for performing HZ operations
On Mon, Sep 26, 2016 at 5:10 PM, Nanley Chery wrote:
> Create a function that performs one of three HiZ operations -
> depth/stencil clears, HiZ resolve, and depth resolves.
>
> Signed-off-by: Nanley Chery
>
> ---
>
> v2. Add documentation
> Fix the alignment check
> Don't minify clear rectangle (Jason)
> Use blorp enums (Jason)
> Enable depth stalls and flushes
> Use full RT rectangle for resolve ops
> Add stencil clear todo
>
> src/intel/vulkan/anv_genX.h| 3 +
> src/intel/vulkan/gen7_cmd_buffer.c | 6 ++
> src/intel/vulkan/gen8_cmd_buffer.c | 167 ++
> +++
> 3 files changed, 176 insertions(+)
>
> diff --git a/src/intel/vulkan/anv_genX.h b/src/intel/vulkan/anv_genX.h
> index 02e79c2..ad3bec9 100644
> --- a/src/intel/vulkan/anv_genX.h
> +++ b/src/intel/vulkan/anv_genX.h
> @@ -58,6 +58,9 @@ genX(emit_urb_setup)(struct anv_device *device, struct
> anv_batch *batch,
> unsigned vs_entry_size, unsigned gs_entry_size,
> const struct gen_l3_config *l3_config);
>
> +void genX(cmd_buffer_do_hz_op)(struct anv_cmd_buffer *cmd_buffer,
> + enum blorp_hiz_op op);
> +
> VkResult
> genX(graphics_pipeline_create)(VkDevice _device,
> struct anv_pipeline_cache *cache,
> diff --git a/src/intel/vulkan/gen7_cmd_buffer.c
> b/src/intel/vulkan/gen7_cmd_buffer.c
> index b627ef0..78b5ac7 100644
> --- a/src/intel/vulkan/gen7_cmd_buffer.c
> +++ b/src/intel/vulkan/gen7_cmd_buffer.c
> @@ -323,6 +323,12 @@ genX(cmd_buffer_flush_dynamic_state)(struct
> anv_cmd_buffer *cmd_buffer)
> cmd_buffer->state.dirty = 0;
> }
>
> +void
> +genX(cmd_buffer_do_hz_op)(struct anv_cmd_buffer *cmd_buffer,
> + enum blorp_hiz_op op)
> +{
>
This should have an anv_finishme in it.
> +}
> +
> void genX(CmdSetEvent)(
> VkCommandBuffer commandBuffer,
> VkEvent event,
> diff --git a/src/intel/vulkan/gen8_cmd_buffer.c
> b/src/intel/vulkan/gen8_cmd_buffer.c
> index 7058608..a13413c 100644
> --- a/src/intel/vulkan/gen8_cmd_buffer.c
> +++ b/src/intel/vulkan/gen8_cmd_buffer.c
> @@ -399,6 +399,173 @@ genX(cmd_buffer_flush_compute_state)(struct
> anv_cmd_buffer *cmd_buffer)
> genX(cmd_buffer_apply_pipe_flushes)(cmd_buffer);
> }
>
> +
> +/**
> + * Emit the HZ_OP packet in the sequence specified by the BDW PRM section
> + * entitled: "Optimized Depth Buffer Clear and/or Stencil Buffer Clear."
> + *
> + * \todo Enable Stencil Buffer-only clears
> + */
> +void
> +genX(cmd_buffer_do_hz_op)(struct anv_cmd_buffer *cmd_buffer,
> + enum blorp_hiz_op op)
> +{
> + struct anv_cmd_state *cmd_state = &cmd_buffer->state;
> + const struct anv_image_view *iview =
> + anv_cmd_buffer_get_depth_stencil_view(cmd_buffer);
> +
> + if (iview == NULL || !anv_image_has_hiz(iview->image))
> + return;
> +
> + const uint32_t ds = cmd_state->subpass->depth_stencil_attachment;
> + const bool full_surface_op =
> + cmd_state->render_area.extent.width == iview->extent.width
> &&
> + cmd_state->render_area.extent.height ==
> iview->extent.height;
>
It's probably a bit redundant, but we might as well check
render_area.offset == 0. I realize that, from API requirements, if the
extents match then offset must be 0, but it's not incredibly obvious and
the check won't hurt that much.
> +
> + /* Validate that we can perform the HZ operation and that it's
> necessary. */
> + switch (op) {
> + case BLORP_HIZ_OP_DEPTH_CLEAR:
> + if (cmd_buffer->state.pass->attachments[ds].load_op !=
> + VK_ATTACHMENT_LOAD_OP_CLEAR)
> + return;
> +
> + /* Apply alignment restrictions. Despite the BDW PRM mentioning
> this is
> + * only needed for a depth buffer surface type of D16_UNORM, testing
> + * showed it to be necessary for other depth formats as well
> + * (e.g., D32_FLOAT).
> + */
> + if (!full_surface_op) {
> +
> + struct isl_extent2d px_dim;
>
Would it be better to call this hiz_block_size_px? That follows the ISL
naming convention a bit better.
> +#if GEN_GEN == 8
>
Mind making this <= 8? I know it's in a gen8+ file, but <= 8 makes it
clear that the else case is >= 9 and not != 8.
> + /* Pre-SKL, HiZ has an 8x4 sample block. As the number of samples
> + * increases, the number of pixels representable by this block
> + * decreases by a factor of the sample dimensions. Sample
> dimensions
> + * scale following the MSAA interleaved pattern.
> + *
> + * Sample|Sample|Pixel
> + * Count |Dim |Dim
> + * ===
> + *1 | 1x1 | 8x4
> + *2 | 2x1 | 4x4
> + *4 | 2x2 | 4x2
> + *8 | 4x2 | 2x2
> + * 16 | 4x4 | 2x1
> + *
> + * T
Re: [Mesa-dev] [PATCH 2/2] radv: Add new flag for LLVM dependecies with vulkan
On 3 October 2016 at 05:45, Tobias Droste wrote: > This reuse the same logic gallium uses to determine if LLVM is needed or > not: > --enable-vulkan-llvm is set to yes if at least one vulkan driver is > active and the host is i3*6 or x86_64. > To build vulkan drivers without LLVM (e.g. intel) one has to add > --disable-vulkan-llvm. > > In order to make this all work the vulkan driver check has to move > either diretcly below or directly above the gallium driver checks. > Move them below the gallium driver stuff. I don't think basing this on gallium is correct, as gallium is used across dirvers, the vulkan drivers are pretty separate at this point, so it should just be a per driver check for llvm, not a vulkan level one. I'll try and clean things up today in there before proposing for master. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] spirv: replace assert() with unreachable()
This fixes an uninitialized warning for is_vertex_input.
---
src/compiler/spirv/vtn_variables.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/compiler/spirv/vtn_variables.c
b/src/compiler/spirv/vtn_variables.c
index 43bb3bc..f431c6f 100644
--- a/src/compiler/spirv/vtn_variables.c
+++ b/src/compiler/spirv/vtn_variables.c
@@ -1054,7 +1054,7 @@ var_decoration_cb(struct vtn_builder *b, struct vtn_value
*val, int member,
is_vertex_input = false;
location += VARYING_SLOT_VAR0;
} else {
- assert(!"Location must be on input or output variable");
+ unreachable("Location must be on input or output variable");
}
if (vtn_var->var) {
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] aubinator: Use less -RS instead of -r for the implicit pager.
From the less man page:
"Warning: when the -r option is used, less cannot keep track of the
actual appearance of the screen (since this depends on how the
screen responds to each type of control character). Thus, various
display problems may result, such as long lines being split in the
wrong place."
Lines which are too long to fit in the terminal would be word wrapped,
but unfortunately less would get confused about which line it was on,
and text would be drawn on top of other text. The most noticable case
was shader assembly, which is frequently too wide for an 80 character
terminal, and thus would be drawn on top of the following state packets,
making them completely unreadable.
Using -R instead of -r fixes this problem by only allowing color escape
sequences. (Notably, Git's implicit pager invocation uses -R.)
Unfortunately, it means our "clear to the end of the line" hack for
extending the blue bar headers won't work anymore.
Word wrapping usually isn't terribly readable, anyway, so we also add
the -S option (chop long lines) to restrict it to the terminal width.
(You can hit the left and right arrow keys to scroll sideways.)
Then, for a new blue bar hack, we can use a printf specifier to pad
the command packet names to be 80 characters long (arbitrarily), which
extends them "far enough" to look good, and doesn't require us to use
ioctls to determine the terminal width.
Signed-off-by: Kenneth Graunke
---
src/intel/tools/aubinator.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
index a31dcb2..5666fe3 100644
--- a/src/intel/tools/aubinator.c
+++ b/src/intel/tools/aubinator.c
@@ -48,7 +48,6 @@
#define CSI "\e["
#define HEADER CSI "37;44m"
#define NORMAL CSI "0m"
-#define CLEAR_TO_EOL CSI "0K"
/* options */
@@ -721,7 +720,7 @@ parse_commands(struct gen_spec *spec, uint32_t *cmds, int
size, int engine)
}
length = gen_group_get_length(inst, p);
- const char *color, *reset_color = CLEAR_TO_EOL NORMAL;
+ const char *color, *reset_color = NORMAL;
uint64_t offset;
if (option_full_decode)
@@ -739,7 +738,7 @@ parse_commands(struct gen_spec *spec, uint32_t *cmds, int
size, int engine)
else
offset = 0;
- printf("%s0x%08lx: 0x%08x: %s%s\n",
+ printf("%s0x%08lx: 0x%08x: %-80s%s\n",
color, offset, p[0],
gen_group_get_name(inst), reset_color);
@@ -1013,7 +1012,7 @@ setup_pager(void)
if (pid == 0) {
close(fds[1]);
dup2(fds[0], 0);
- execlp("less", "less", "-rFi", NULL);
+ execlp("less", "less", "-FRSi", NULL);
}
close(fds[0]);
--
2.10.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH V2 09/11] genX/cmd_buffer: Enable rendering to HiZ
Reviewed-by: Jason Ekstrand
On Mon, Sep 26, 2016 at 5:10 PM, Nanley Chery wrote:
> From: Chad Versace
>
> Nanley Chery:
> (rebase)
> - Resolve conflicts with new anv_batch_emit macro
> (amend)
> - Handle a QPitch TODO
> - Emit 3DSTATE_HIER_DEPTH_BUFFER on pre-BDW systems
> - Only use HiZ for single-subpass renderpasses
> - Emit the HiZ instruction before the stencil instruction to follow the
>optimized clear sequence specified in the PRMs
> - Don't modify clear params
> - Enable resolves when a HiZ buffer is used to ensure depth buffer
> validity
>
> Provides an FPS increase of ~15% on the Sascha triangle and multisampling
> demos.
>
> Signed-off-by: Nanley Chery
>
> ---
>
> v2: Emit zero'ed 3DSTATE_HIER_DEPTH_BUFFER when hiz is disabled
> (Jason, Chad)
>
> src/intel/vulkan/gen8_cmd_buffer.c | 4
> src/intel/vulkan/genX_cmd_buffer.c | 43 ++
>
> 2 files changed, 43 insertions(+), 4 deletions(-)
>
> diff --git a/src/intel/vulkan/gen8_cmd_buffer.c
> b/src/intel/vulkan/gen8_cmd_buffer.c
> index a13413c..14e6a7b 100644
> --- a/src/intel/vulkan/gen8_cmd_buffer.c
> +++ b/src/intel/vulkan/gen8_cmd_buffer.c
> @@ -417,6 +417,10 @@ genX(cmd_buffer_do_hz_op)(struct anv_cmd_buffer
> *cmd_buffer,
> if (iview == NULL || !anv_image_has_hiz(iview->image))
>return;
>
> + /* FIXME: Implement multi-subpass HiZ */
> + if (cmd_buffer->state.pass->subpass_count > 1)
> + return;
> +
> const uint32_t ds = cmd_state->subpass->depth_stencil_attachment;
> const bool full_surface_op =
> cmd_state->render_area.extent.width == iview->extent.width
> &&
> diff --git a/src/intel/vulkan/genX_cmd_buffer.c
> b/src/intel/vulkan/genX_cmd_buffer.c
> index 6a84383..2cb1539 100644
> --- a/src/intel/vulkan/genX_cmd_buffer.c
> +++ b/src/intel/vulkan/genX_cmd_buffer.c
> @@ -1199,6 +1199,7 @@ cmd_buffer_emit_depth_stencil(struct anv_cmd_buffer
> *cmd_buffer)
>anv_cmd_buffer_get_depth_stencil_view(cmd_buffer);
> const struct anv_image *image = iview ? iview->image : NULL;
> const bool has_depth = image && (image->aspects &
> VK_IMAGE_ASPECT_DEPTH_BIT);
> + const bool has_hiz = image != NULL && anv_image_has_hiz(image);
> const bool has_stencil =
>image && (image->aspects & VK_IMAGE_ASPECT_STENCIL_BIT);
>
> @@ -1211,7 +1212,12 @@ cmd_buffer_emit_depth_stencil(struct
> anv_cmd_buffer *cmd_buffer)
> db.SurfaceType = SURFTYPE_2D;
> db.DepthWriteEnable = true;
> db.StencilWriteEnable= has_stencil;
> - db.HierarchicalDepthBufferEnable = false;
> +
> + if (cmd_buffer->state.pass->subpass_count == 1) {
> +db.HierarchicalDepthBufferEnable = has_hiz;
> + } else {
> +anv_finishme("Multiple-subpass HiZ not implemented");
> + }
>
> db.SurfaceFormat = isl_surf_get_depth_format(&device->isl_dev,
>
> &image->depth_surface.isl);
> @@ -1263,6 +1269,36 @@ cmd_buffer_emit_depth_stencil(struct
> anv_cmd_buffer *cmd_buffer)
>}
> }
>
> + if (has_hiz) {
> + anv_batch_emit(&cmd_buffer->batch, GENX(3DSTATE_HIER_DEPTH_BUFFER),
> hdb) {
> + hdb.HierarchicalDepthBufferObjectControlState = GENX(MOCS);
> + hdb.SurfacePitch = image->hiz_surface.isl.row_pitch - 1;
> + hdb.SurfaceBaseAddress = (struct anv_address) {
> +.bo = image->bo,
> +.offset = image->offset + image->hiz_surface.offset,
> + };
> +#if GEN_GEN >= 8
> + /* From the SKL PRM Vol2a:
> + *
> + *The interpretation of this field is dependent on Surface
> Type
> + *as follows:
> + *- SURFTYPE_1D: distance in pixels between array slices
> + *- SURFTYPE_2D/CUBE: distance in rows between array slices
> + *- SURFTYPE_3D: distance in rows between R - slices
> + *
> + * ISL implements HiZ surfaces for 1D depth buffers as 2D.
> Therefore
> + * the depth buffer needs to be checked for the dimension.
> + */
> + hdb.SurfaceQPitch =
> +image->depth_surface.isl.dim == ISL_SURF_DIM_1D ?
> + isl_surf_get_array_pitch_el(&image->hiz_surface.isl) >> 2
> :
> + isl_surf_get_array_pitch_el_rows(&image->hiz_surface.isl)
> >> 2;
> +#endif
> + }
> + } else {
> + anv_batch_emit(&cmd_buffer->batch, GENX(3DSTATE_HIER_DEPTH_BUFFER),
> hdb);
> + }
> +
> /* Emit 3DSTATE_STENCIL_BUFFER */
> if (has_stencil) {
>anv_batch_emit(&cmd_buffer->batch, GENX(3DSTATE_STENCIL_BUFFER),
> sb) {
> @@ -1285,9 +1321,6 @@ cmd_buffer_emit_depth_stencil(struct anv_cmd_buffer
> *cmd_buffer)
>anv_batch_emit(&cmd_buffer->batch, GENX(3DSTATE_STENCIL_BUFFER),
> sb);
> }
>
> - /* Disable hierarchial depth buffers. */
> - anv_batch_emit(&cmd_buffer->batch, GENX(3DSTATE_HIER_DEPTH_BUFFER),
> hz);
> -
> /* Clear the clear
[Mesa-dev] [PATCH] intel: use the correct format specifier for printing uint64_t
Fixes a bunch of warnings in 32-bit builds.
---
src/intel/tools/aubinator.c | 17 +
src/intel/tools/decoder.c | 7 ---
2 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
index a31dcb2..9b32e5b 100644
--- a/src/intel/tools/aubinator.c
+++ b/src/intel/tools/aubinator.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -96,7 +97,7 @@ print_dword_val(struct gen_field_iterator *iter, uint64_t
offset,
const int dword = f->start / 32;
if (*dword_num != dword) {
- printf("0x%08lx: 0x%08x : Dword %d\n",
+ printf("0x%08"PRIx64": 0x%08x : Dword %d\n",
offset + 4 * dword, iter->p[dword], dword);
*dword_num = dword;
}
@@ -296,10 +297,10 @@ handle_media_interface_descriptor_load(struct gen_spec
*spec, uint32_t *p)
start = instruction_base + descriptors[0];
if (!valid_offset(start)) {
- printf("kernel: %08lx \n", start);
+ printf("kernel: %08"PRIx64" \n", start);
continue;
} else {
- printf("kernel: %08lx\n", start);
+ printf("kernel: %08"PRIx64"\n", start);
}
insns = (struct brw_instruction *) (gtt + start);
@@ -397,7 +398,7 @@ handle_3dstate_vs(struct gen_spec *spec, uint32_t *p)
}
if (vs_enable) {
- printf("instruction_base %08lx, start %08lx\n",
+ printf("instruction_base %08"PRIx64", start %08"PRIx64"\n",
instruction_base, start);
insns = (struct brw_instruction *) (gtt + instruction_base + start);
@@ -421,7 +422,7 @@ handle_3dstate_hs(struct gen_spec *spec, uint32_t *p)
hs_enable = p[2] & 0x8000;
if (hs_enable) {
- printf("instruction_base %08lx, start %08lx\n",
+ printf("instruction_base %08"PRIx64", start %08"PRIx64"\n",
instruction_base, start);
insns = (struct brw_instruction *) (gtt + instruction_base + start);
@@ -739,7 +740,7 @@ parse_commands(struct gen_spec *spec, uint32_t *cmds, int
size, int engine)
else
offset = 0;
- printf("%s0x%08lx: 0x%08x: %s%s\n",
+ printf("%s0x%08"PRIx64": 0x%08x: %s%s\n",
color, offset, p[0],
gen_group_get_name(inst), reset_color);
@@ -754,7 +755,7 @@ parse_commands(struct gen_spec *spec, uint32_t *cmds, int
size, int engine)
if (dword_num > 0)
token = print_iterator_values(&iter, &idx);
if (token != NULL) {
-printf("0x%08lx: 0x%08x : Dword %d\n",
+printf("0x%08"PRIx64": 0x%08x : Dword %d\n",
offset + 4 * idx, p[idx], idx);
handle_struct_decode(spec,token, &p[idx]);
token = NULL;
@@ -971,7 +972,7 @@ aub_file_decode_batch(struct aub_file *file, struct
gen_spec *spec)
break;
case MAKE_HEADER(TYPE_AUB, OPCODE_NEW_AUB, SUBOPCODE_MEM_WRITE):
printf("memory write block (dwords %d):\n", h & 0x);
- printf(" address 0x%lx\n", *(uint64_t *) &p[1]);
+ printf(" address 0x%"PRIx64"\n", *(uint64_t *) &p[1]);
data_type = (p[3] >> 20) & 0xff;
if (data_type != 0)
printf(" data type 0x%x\n", data_type);
diff --git a/src/intel/tools/decoder.c b/src/intel/tools/decoder.c
index be3558b..4cbaab2 100644
--- a/src/intel/tools/decoder.c
+++ b/src/intel/tools/decoder.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
@@ -529,11 +530,11 @@ gen_field_iterator_next(struct gen_field_iterator *iter)
case GEN_TYPE_UNKNOWN:
case GEN_TYPE_INT:
snprintf(iter->value, sizeof(iter->value),
- "%ld", field(v.qw, f->start, f->end));
+ "%"PRId64, field(v.qw, f->start, f->end));
break;
case GEN_TYPE_UINT:
snprintf(iter->value, sizeof(iter->value),
- "%lu", field(v.qw, f->start, f->end));
+ "%"PRIu64, field(v.qw, f->start, f->end));
break;
case GEN_TYPE_BOOL:
snprintf(iter->value, sizeof(iter->value),
@@ -545,7 +546,7 @@ gen_field_iterator_next(struct gen_field_iterator *iter)
case GEN_TYPE_ADDRESS:
case GEN_TYPE_OFFSET:
snprintf(iter->value, sizeof(iter->value),
- "0x%08lx", field_address(v.qw, f->start, f->end));
+ "0x%08"PRIx64, field_address(v.qw, f->start, f->end));
break;
case GEN_TYPE_STRUCT:
snprintf(iter->value, sizeof(iter->value),
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Only emit 1 viewport when possible.
Reviewed-by: Ian Romanick
On 09/26/2016 11:23 AM, Kenneth Graunke wrote:
> In core profile, we support up to 16 viewports. However, in the
> majority of cases, only 1 of them is actually used - we only need
> the others if the last shader stage prior to the rasterizer writes
> gl_ViewportIndex.
>
> Processing all 16 viewports adds additional CPU overhead, which hurts
> CPU-intensive workloads such as Glamor. This meant that switching to
> core profile actually penalized Glamor to an extent, which is
> unfortunate.
>
> This patch tracks the number of relevant viewports, switching between
> 1 and ctx->Const.MaxViewports if gl_ViewportIndex is written. A new
> BRW_NEW_VIEWPORT_COUNT flag tracks this. This could mean re-emitting
> viewport state when switching, but hopefully this is offset by doing
> 1/16th of the work in the common case. The new flag is also lighter
> weight than BRW_NEW_VUE_MAP_GEOM_OUT, which we were using in one case.
>
> According to Eric Anholt, this reduces the CPU overhead of scissor and
> viewport state changes n Glamor from 2.5% or so to .8% or so.
>
> Cc: Eric Anholt
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/brw_cc.c | 10 +++---
> src/mesa/drivers/dri/i965/brw_context.c | 1 +
> src/mesa/drivers/dri/i965/brw_context.h | 9 +
> src/mesa/drivers/dri/i965/brw_gs_state.c| 6 --
> src/mesa/drivers/dri/i965/brw_state_upload.c| 11 +++
> src/mesa/drivers/dri/i965/gen6_clip_state.c | 16 +++-
> src/mesa/drivers/dri/i965/gen6_scissor_state.c | 10 +++---
> src/mesa/drivers/dri/i965/gen6_viewport_state.c | 22 +++---
> src/mesa/drivers/dri/i965/gen7_viewport_state.c | 10 +++---
> src/mesa/drivers/dri/i965/gen8_viewport_state.c | 10 +++---
> 10 files changed, 75 insertions(+), 30 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_cc.c
> b/src/mesa/drivers/dri/i965/brw_cc.c
> index 5c58b44..b11d7c8 100644
> --- a/src/mesa/drivers/dri/i965/brw_cc.c
> +++ b/src/mesa/drivers/dri/i965/brw_cc.c
> @@ -44,12 +44,15 @@ brw_upload_cc_vp(struct brw_context *brw)
> struct gl_context *ctx = &brw->ctx;
> struct brw_cc_viewport *ccv;
>
> + /* BRW_NEW_VIEWPORT_COUNT */
> + const unsigned viewport_count = brw->clip.viewport_count;
> +
> ccv = brw_state_batch(brw, AUB_TRACE_CC_VP_STATE,
> - sizeof(*ccv) * ctx->Const.MaxViewports, 32,
> + sizeof(*ccv) * viewport_count, 32,
> &brw->cc.vp_offset);
>
> /* _NEW_TRANSFORM */
> - for (unsigned i = 0; i < ctx->Const.MaxViewports; i++) {
> + for (unsigned i = 0; i < viewport_count; i++) {
>if (ctx->Transform.DepthClamp) {
> /* _NEW_VIEWPORT */
> ccv[i].min_depth = MIN2(ctx->ViewportArray[i].Near,
> @@ -77,7 +80,8 @@ const struct brw_tracked_state brw_cc_vp = {
>.mesa = _NEW_TRANSFORM |
>_NEW_VIEWPORT,
>.brw = BRW_NEW_BATCH |
> - BRW_NEW_BLORP,
> + BRW_NEW_BLORP |
> + BRW_NEW_VIEWPORT_COUNT,
> },
> .emit = brw_upload_cc_vp
> };
> diff --git a/src/mesa/drivers/dri/i965/brw_context.c
> b/src/mesa/drivers/dri/i965/brw_context.c
> index 6efad78..b0eec16 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.c
> +++ b/src/mesa/drivers/dri/i965/brw_context.c
> @@ -1085,6 +1085,7 @@ brwCreateContext(gl_api api,
> brw->prim_restart.enable_cut_index = false;
> brw->gs.enabled = false;
> brw->sf.viewport_transform_enable = true;
> + brw->clip.viewport_count = 1;
>
> brw->predicate.state = BRW_PREDICATE_STATE_RENDER;
>
> diff --git a/src/mesa/drivers/dri/i965/brw_context.h
> b/src/mesa/drivers/dri/i965/brw_context.h
> index 00f0adc..b27fe51 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.h
> +++ b/src/mesa/drivers/dri/i965/brw_context.h
> @@ -226,6 +226,7 @@ enum brw_state_id {
> BRW_STATE_URB_SIZE,
> BRW_STATE_CC_STATE,
> BRW_STATE_BLORP,
> + BRW_STATE_VIEWPORT_COUNT,
> BRW_NUM_STATE_BITS
> };
>
> @@ -294,6 +295,7 @@ enum brw_state_id {
> #define BRW_NEW_PROGRAM_CACHE (1ull << BRW_STATE_PROGRAM_CACHE)
> #define BRW_NEW_STATE_BASE_ADDRESS (1ull <<
> BRW_STATE_STATE_BASE_ADDRESS)
> #define BRW_NEW_VUE_MAP_GEOM_OUT(1ull << BRW_STATE_VUE_MAP_GEOM_OUT)
> +#define BRW_NEW_VIEWPORT_COUNT (1ull << BRW_STATE_VIEWPORT_COUNT)
> #define BRW_NEW_TRANSFORM_FEEDBACK (1ull <<
> BRW_STATE_TRANSFORM_FEEDBACK)
> #define BRW_NEW_RASTERIZER_DISCARD (1ull <<
> BRW_STATE_RASTERIZER_DISCARD)
> #define BRW_NEW_STATS_WM(1ull << BRW_STATE_STATS_WM)
> @@ -1160,6 +1162,13 @@ struct brw_context
> * instead of vp_bo.
> */
>uint32_t vp_offset;
> +
> + /**
> + * The number of viewports to use. If gl_ViewportIndex is written,
> + * we can have up to ctx->Const.MaxViewports viewports. If not,
> +
Re: [Mesa-dev] Mesa 12.1.0 release plan (Was Re: Next Mesa release, anyone?)
On Thu, Sep 29, 2016 at 10:56 AM, Emil Velikov wrote: > On 28 September 2016 at 19:53, Marek Olšák wrote: >> Hi, >> >> It's been almost 4 months since the 12.0 branch was created, and soon >> it will have been 3 months since Mesa 12.0 was released. >> >> Is there any reason we haven't created the stable branch yet? >> >> Ideally, we would time the release so that it's 1-2 months before fall >> distribution releases. >> > > Thanks Marek ! > > In all honesty I was secretly hoping that we'll get Dave/Bas RADV for > 12.1. With the topic of which would be 'the default' Vulkan driver for > ATI/AMD hardware to be considered at a later stage. btw, I pushed libdrm release that I think etnaviv was waiting for.. not sure what else is needed before merging etnaviv gallium driver, but if at all possible, it would be nice to land that before the branch point too. BR, -R > That said here are the tentative dates: > > Oct 7/14 2016 - Feature freeze/Release candidate 1 > Oct 14/21 2016 - Release candidate 2 > Oct 21/28 2016 - Release candidate 3/final release > > Fwiw I'm still in favour of getting RADV in even if it's not > perfect/feature complete. Devs, let me know if there's a "must have" > feature that we want in 12.1. > > Thanks > Emil > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH V2 10/11] genX/cmd_buffer: Enable fast depth clears
On Tue, Sep 27, 2016 at 3:23 PM, Nanley Chery wrote: > On Tue, Sep 27, 2016 at 03:12:17PM -0700, Chad Versace wrote: > > On Tue 27 Sep 2016, Nanley Chery wrote: > > > On Tue, Sep 27, 2016 at 11:00:21AM -0700, Chad Versace wrote: > > > > > > As a consequence of that reasoning, we should set > 3DSTATE_CLEAR_PARAMS.DepthClearValueValid = 1 > > > > whenever hiz is enabled, even if we don't care about the actual > clear value. > The logic seems to imply that we can't trust the context to save/restore our depth clear value so we have to set it every time. At the very least, once per batch? In any case, I doubt there's all that much cost involved in emitting 3DSTATE_CLEAR_PARAMS so I don't think re-emitting it is that big of a deal. > > > > > > In the V3, I plan to emit that packet once at device initialization > time > > > HSW+, and to always emit it (in the expected location) for IVB/BYT. > Only > > > the latter platforms have the restriction that it must always be > > > programmed with the other depth/stencil commands. > > > > Is there any benefit to emitting it multiple times on ivb/byt? Does > > emitting once during initialization, as for hsw, also work for ivb/byt? > > If so, the code is cleaner if the two gens share the same workaround > > code. > > The benefit for emitting it multiple times on IVB/BYT is that we're > (possibly) following the oddly-worded programming note for the packet: > >From the IVB PRM Vol2P1, 11.5.5.4 3DSTATE_CLEAR_PARAMS: > > 3DSTATE_CLEAR_PARAMS must always be programmed in the along with > the other Depth/Stencil state commands(i.e. 3DSTATE_DEPTH_BUFFER, > 3DSTATE_STENCIL_BUFFER, or 3DSTATE_HIER_DEPTH_BUFFER) > > HSW+ doesn't have this restriction, so we're free to only do it once. > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium/drivers: initialize pipe_resource::next to NULL
On 04/10/16 01:53 AM, Roland Scheidegger wrote: > In an ideal world everybody would zero-intialize the template I suppose > - then it would easily survive such interface changes. As long as there are no fields where 0 isn't a safe value... What's needed is an explicit definition of whether it's the caller's or callee's responsibility to initialize the next field (in particular, and any other fields in general). Are there any cases where the resource_create caller needs to pass in a non-NULL next field value? Note that with the original problem I fixed in radeon, the caller wasn't in state tracker code but in driver internal code. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH V2 00/11] anv: Implement HiZ for basic cases
The whole thing is Reviewed-by: Jason Ekstrand I'm still a little concerned about CLEAR_PARAMS in patch 10, but once chad's happy, I'll be happy. On Mon, Sep 26, 2016 at 5:10 PM, Nanley Chery wrote: > This series is the second revision of the series found here: > https://lists.freedesktop.org/archives/mesa-dev/2016-September/127687.html > > Comments from the first were addressed and the code was rebased onto > the upstream master. > > Cc: Chad Versace > Cc: Jason Ekstrand > > Chad Versace (4): > anv: Add anv_image::hiz_surface > anv: Add func anv_image_has_hiz() > anv: Allocate hiz surface > genX/cmd_buffer: Enable rendering to HiZ > > Jason Ekstrand (2): > anv: Move BindImageMemory to anv_image.c > anv/image: Memset hiz surfaces to 0 when binding memory > > Nanley Chery (5): > isl: Correct a comment in the isl_format enum > isl: Update isl_surf_get_hiz_surf() > anv/cmd_buffer: Add code for performing HZ operations > genX/cmd_buffer: Enable fast depth clears > anv/TODO: Update the HiZ task > > src/intel/isl/isl.c| 39 ++-- > src/intel/isl/isl.h| 2 +- > src/intel/vulkan/TODO | 2 +- > src/intel/vulkan/anv_device.c | 20 - > src/intel/vulkan/anv_genX.h| 3 + > src/intel/vulkan/anv_image.c | 88 +- > src/intel/vulkan/anv_pass.c| 13 +++ > src/intel/vulkan/anv_private.h | 12 +++ > src/intel/vulkan/gen7_cmd_buffer.c | 6 ++ > src/intel/vulkan/gen8_cmd_buffer.c | 177 ++ > +++ > src/intel/vulkan/genX_cmd_buffer.c | 47 -- > 11 files changed, 371 insertions(+), 38 deletions(-) > > -- > 2.10.0 > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH V2 10/11] genX/cmd_buffer: Enable fast depth clears
On Mon, Oct 3, 2016 at 6:11 PM, Jason Ekstrand wrote: > On Tue, Sep 27, 2016 at 3:23 PM, Nanley Chery > wrote: > >> On Tue, Sep 27, 2016 at 03:12:17PM -0700, Chad Versace wrote: >> > On Tue 27 Sep 2016, Nanley Chery wrote: >> > > On Tue, Sep 27, 2016 at 11:00:21AM -0700, Chad Versace wrote: >> > >> > > > As a consequence of that reasoning, we should set >> 3DSTATE_CLEAR_PARAMS.DepthClearValueValid = 1 >> > > > whenever hiz is enabled, even if we don't care about the actual >> clear value. >> > > The logic seems to imply that we can't trust the context to save/restore > our depth clear value so we have to set it every time. At the very least, > once per batch? In any case, I doubt there's all that much cost involved > in emitting 3DSTATE_CLEAR_PARAMS so I don't think re-emitting it is that > big of a deal. > Thinking about it a bit more... We only set up dept/stencil packets once per subpass and we only do clears once per subpass so... I don't think we're actually saving anything by emitting it at clear time rather than at depth/stencil setup time. It is a bit more convenient because the clear values may be more accessible at clear time. As far as "should we emit 3DSTATE_CLEAR_PARAMS all the time?" Let's not go to any heroics to try and avoid re-emitting it. Once per subpass is not a big deal at all. --Jason > > > >> > > In the V3, I plan to emit that packet once at device initialization >> time >> > > HSW+, and to always emit it (in the expected location) for IVB/BYT. >> Only >> > > the latter platforms have the restriction that it must always be >> > > programmed with the other depth/stencil commands. >> > >> > Is there any benefit to emitting it multiple times on ivb/byt? Does >> > emitting once during initialization, as for hsw, also work for ivb/byt? >> > If so, the code is cleaner if the two gens share the same workaround >> > code. >> >> The benefit for emitting it multiple times on IVB/BYT is that we're >> (possibly) following the oddly-worded programming note for the packet: >> >>From the IVB PRM Vol2P1, 11.5.5.4 3DSTATE_CLEAR_PARAMS: >> >> 3DSTATE_CLEAR_PARAMS must always be programmed in the along with >> the other Depth/Stencil state commands(i.e. 3DSTATE_DEPTH_BUFFER, >> 3DSTATE_STENCIL_BUFFER, or 3DSTATE_HIER_DEPTH_BUFFER) >> >> HSW+ doesn't have this restriction, so we're free to only do it once. >> > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] radv: Add new flag for LLVM dependecies with vulkan
I was looking at a per driver check for vulkan, but then this can't reuse the existing functions to check llvm version. The LLVM version checks are also the reason this is done is such a weird way for gallium. It doesn't make sense there too and should be per driver too. This patch was just the way of the least resistance by reusing as much as possible and make it actually work. If you have something better, I don't mind if you ignore this :-) Tobias Am Dienstag, 4. Oktober 2016, 10:25:38 CEST schrieb Dave Airlie: > On 3 October 2016 at 05:45, Tobias Droste wrote: > > This reuse the same logic gallium uses to determine if LLVM is needed or > > not: > > --enable-vulkan-llvm is set to yes if at least one vulkan driver is > > active and the host is i3*6 or x86_64. > > To build vulkan drivers without LLVM (e.g. intel) one has to add > > --disable-vulkan-llvm. > > > > In order to make this all work the vulkan driver check has to move > > either diretcly below or directly above the gallium driver checks. > > Move them below the gallium driver stuff. > > I don't think basing this on gallium is correct, as gallium is used across > dirvers, the vulkan drivers are pretty separate at this point, so it should > just be a per driver check for llvm, not a vulkan level one. > > I'll try and clean things up today in there before proposing for master. > > Dave. -- Mit freundlichen Grüßen Tobias Droste ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium/drivers: initialize pipe_resource::next to NULL
Am 04.10.2016 um 03:16 schrieb Michel Dänzer: > On 04/10/16 01:53 AM, Roland Scheidegger wrote: >> In an ideal world everybody would zero-intialize the template I suppose >> - then it would easily survive such interface changes. > > As long as there are no fields where 0 isn't a safe value... That's true, but for interface additions you can usually design them around 0 being a safe value. (Of course, how this usually works is these fields are interpreted by the drivers, and in this case just about anything is usually safe, as long as the driver actually doesn't implement a new feature.) > > What's needed is an explicit definition of whether it's the caller's or > callee's responsibility to initialize the next field (in particular, and > any other fields in general). Are there any cases where the > resource_create caller needs to pass in a non-NULL next field value? > > Note that with the original problem I fixed in radeon, the caller wasn't > in state tracker code but in driver internal code. > I suppose it's never necessary to pass a non-NULL value there (there isn't really a definition how a driver should create such a resource). Still, passing explicitly bogus values there in the template just irks me. But if it's easier, doing it in the driver ought to be ok... Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] radv initial submission
Hi all, I fully expect this won't make it to the list in one piece due to size. I've pushed the same patchset to https://github.com/airlied/mesa/tree/radv-submit This is an initial submission of the open source radv vulkan driver for AMD GPUs supported by the amdgpu driver. It is a project Bas and I started some months ago as an interesting learning experience and it's been great to see it get this far in such a short time. This driver is in no way to be considered conformant or called such. It has NOT passed the vulkan conformance suite or ever been submitted to Khronos. It prints a big warning on startup to this effect. In saying that, it runs quite well with Dota 2, Talos Principle and vkQuake in our testing so far. Future plans are to add support for various hw speedups (fast clears), missing things like spilling, and multiple queues along with finishing out things like geom/tess shaders. Also trying to reuse code between this and the radeonsi driver where possible. radv already reuses the LLVM compiler backend and the addrlib code. I've split things out into 4 patches, 3 just add code files to various places and number 4 intergrates the build system changes so they are easier to review. Regards, Dave (and on behalf of Bas). ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] radv/winsys: import the amdgpu winsys for the radv vulkan driver.
From: Dave Airlie
This just brings these files into the tree, it doesn't integrate
them with the build system.
The radv winsys is based on the gallium one with some changes,
due to how command buffers are built and lack of flushing behaviour.
Authors: Bas Nieuwenhuizen and Dave Airlie
Signed-off-by: Dave Airlie
---
src/amd/vulkan/radv_radeon_winsys.h| 332 +
src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c | 297
src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.h | 50 ++
src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c | 778 +
src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.h | 52 ++
src/amd/vulkan/winsys/amdgpu/radv_amdgpu_surface.c | 523 ++
src/amd/vulkan/winsys/amdgpu/radv_amdgpu_surface.h | 29 +
src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.c | 359 ++
src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.h | 32 +
.../winsys/amdgpu/radv_amdgpu_winsys_public.h | 30 +
10 files changed, 2482 insertions(+)
create mode 100644 src/amd/vulkan/radv_radeon_winsys.h
create mode 100644 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c
create mode 100644 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.h
create mode 100644 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c
create mode 100644 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.h
create mode 100644 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_surface.c
create mode 100644 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_surface.h
create mode 100644 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.c
create mode 100644 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.h
create mode 100644 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys_public.h
diff --git a/src/amd/vulkan/radv_radeon_winsys.h
b/src/amd/vulkan/radv_radeon_winsys.h
new file mode 100644
index 000..1297583
--- /dev/null
+++ b/src/amd/vulkan/radv_radeon_winsys.h
@@ -0,0 +1,332 @@
+/*
+ * Copyright © 2016 Red Hat.
+ * Copyright © 2016 Bas Nieuwenhuizen
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+#pragma once
+
+#include
+#include
+#include
+#include "main/macros.h"
+#include "ac_radeon_winsys.h"
+
+#define FREE(x) free(x)
+
+enum radeon_bo_domain { /* bitfield */
+ RADEON_DOMAIN_GTT = 2,
+ RADEON_DOMAIN_VRAM = 4,
+ RADEON_DOMAIN_VRAM_GTT = RADEON_DOMAIN_VRAM | RADEON_DOMAIN_GTT
+};
+
+enum radeon_bo_flag { /* bitfield */
+ RADEON_FLAG_GTT_WC =(1 << 0),
+ RADEON_FLAG_CPU_ACCESS =(1 << 1),
+ RADEON_FLAG_NO_CPU_ACCESS = (1 << 2),
+};
+
+enum radeon_bo_usage { /* bitfield */
+ RADEON_USAGE_READ = 2,
+ RADEON_USAGE_WRITE = 4,
+ RADEON_USAGE_READWRITE = RADEON_USAGE_READ | RADEON_USAGE_WRITE
+};
+
+enum ring_type {
+ RING_GFX = 0,
+ RING_COMPUTE,
+ RING_DMA,
+ RING_UVD,
+ RING_VCE,
+ RING_LAST,
+};
+
+struct radeon_winsys_cs {
+ unsigned cdw; /* Number of used dwords. */
+ unsigned max_dw; /* Maximum number of dwords. */
+ uint32_t *buf; /* The base pointer of the chunk. */
+};
+
+struct radeon_info {
+ /* PCI info: domain:bus:dev:func */
+ uint32_tpci_domain;
+ uint32_tpci_bus;
+ uint32_tpci_dev;
+ uint32_tpci_func;
+
+ /* Device info. */
+ uint32_tpci_id;
+ enum radeon_family family;
+ const char *name;
+ enum chip_class chip_class;
+ uint32_tgart_page_size;
+ uint64_tgart_size;
+ uint64_tvram_size;
+ boolhas_dedicated_vram;
+ bool has_virtual_memory;
+ boolgfx_ib_pad_with_type2;
+ bool has_sdma;
+ bool has_uvd;
+
[Mesa-dev] [PATCH 4/4] radv: toplevel configure/make changes required to build
From: Dave Airlie
This moves some of the llvm checks around to allow them
to be used for non-gallium drivers as well.
radv requires llvm 3.9.0 as vulkan requires compute shaders.
Authors: Bas Nieuwenhuizen and Dave Airlie
Signed-off-by: Dave Airlie
---
configure.ac| 33 ++---
src/Makefile.am | 7 ++-
2 files changed, 32 insertions(+), 8 deletions(-)
diff --git a/configure.ac b/configure.ac
index 1bfac3b..634f3c3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1704,6 +1704,10 @@ if test -n "$with_vulkan_drivers"; then
HAVE_INTEL_VULKAN=yes;
;;
+xradeon)
+PKG_CHECK_MODULES([AMDGPU], [libdrm_amdgpu >=
$LIBDRM_AMDGPU_REQUIRED])
+HAVE_RADEON_VULKAN=yes;
+ ;;
*)
AC_MSG_ERROR([Vulkan driver '$driver' does not exist])
;;
@@ -2187,7 +2191,7 @@ if test "x$enable_gallium_llvm" = xauto; then
i*86|x86_64|amd64) enable_gallium_llvm=yes;;
esac
fi
-if test "x$enable_gallium_llvm" = xyes; then
+if test "x$enable_gallium_llvm" = xyes || test "x$HAVE_RADEON_VULKAN" = xyes;
then
if test -n "$llvm_prefix"; then
AC_PATH_TOOL([LLVM_CONFIG], [llvm-config], [no], ["$llvm_prefix/bin"])
else
@@ -2357,10 +2361,7 @@ radeon_llvm_check() {
else
amdgpu_llvm_target_name='amdgpu'
fi
-if test "x$enable_gallium_llvm" != "xyes"; then
-AC_MSG_ERROR([--enable-gallium-llvm is required when building $1])
-fi
-llvm_check_version_for "3" "6" "0" $1
+llvm_check_version_for $2 $3 $4 $1
if test true && $LLVM_CONFIG --targets-built | grep -iqvw
$amdgpu_llvm_target_name ; then
AC_MSG_ERROR([LLVM $amdgpu_llvm_target_name not enabled in your LLVM
build.])
fi
@@ -2371,6 +2372,13 @@ radeon_llvm_check() {
fi
}
+radeon_gallium_llvm_check() {
+if test "x$enable_gallium_llvm" != "xyes"; then
+AC_MSG_ERROR([--enable-gallium-llvm is required when building $1])
+fi
+radeon_llvm_check $*
+}
+
swr_llvm_check() {
gallium_require_llvm $1
if test ${LLVM_VERSION_INT} -lt 306; then
@@ -2455,7 +2463,7 @@ if test -n "$with_gallium_drivers"; then
gallium_require_drm "Gallium R600"
gallium_require_drm_loader
if test "x$enable_opencl" = xyes; then
-radeon_llvm_check "r600g"
+radeon_gallium_llvm_check "r600g" "3" "6" "0"
LLVM_COMPONENTS="${LLVM_COMPONENTS} bitreader asmparser"
fi
;;
@@ -2465,7 +2473,7 @@ if test -n "$with_gallium_drivers"; then
PKG_CHECK_MODULES([AMDGPU], [libdrm_amdgpu >=
$LIBDRM_AMDGPU_REQUIRED])
gallium_require_drm "radeonsi"
gallium_require_drm_loader
-radeon_llvm_check "radeonsi"
+radeon_gallium_llvm_check "radeonsi" "3" "6" "0"
require_egl_drm "radeonsi"
;;
xnouveau)
@@ -2584,6 +2592,10 @@ if test "x$MESA_LLVM" != x0; then
fi
fi
+if test "x$HAVE_RADEON_VULKAN" != "x0"; then
+radeon_llvm_check "radv" "3" "9" "0"
+fi
+
AM_CONDITIONAL(HAVE_GALLIUM_SVGA, test "x$HAVE_GALLIUM_SVGA" = xyes)
AM_CONDITIONAL(HAVE_GALLIUM_I915, test "x$HAVE_GALLIUM_I915" = xyes)
AM_CONDITIONAL(HAVE_GALLIUM_ILO, test "x$HAVE_GALLIUM_ILO" = xyes)
@@ -2621,8 +2633,13 @@ AM_CONDITIONAL(HAVE_R200_DRI, test x$HAVE_R200_DRI =
xyes)
AM_CONDITIONAL(HAVE_RADEON_DRI, test x$HAVE_RADEON_DRI = xyes)
AM_CONDITIONAL(HAVE_SWRAST_DRI, test x$HAVE_SWRAST_DRI = xyes)
+AM_CONDITIONAL(HAVE_RADEON_VULKAN, test "x$HAVE_RADEON_VULKAN" = xyes)
AM_CONDITIONAL(HAVE_INTEL_VULKAN, test "x$HAVE_INTEL_VULKAN" = xyes)
+AM_CONDITIONAL(HAVE_AMD_DRIVERS, test "x$HAVE_GALLIUM_R600" = xyes -o \
+ "x$HAVE_GALLIUM_RADEONSI" = xyes -o \
+ "x$HAVE_RADEON_VULKAN" = xyes)
+
AM_CONDITIONAL(HAVE_INTEL_DRIVERS, test "x$HAVE_INTEL_VULKAN" = xyes -o \
"x$HAVE_I965_DRI" = xyes)
@@ -2713,6 +2730,8 @@ dnl Substitute the config
AC_CONFIG_FILES([Makefile
src/Makefile
src/amd/Makefile
+ src/amd/common/Makefile
+ src/amd/vulkan/Makefile
src/compiler/Makefile
src/egl/Makefile
src/egl/main/egl.pc
diff --git a/src/Makefile.am b/src/Makefile.am
index 551f431..6a35f19 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -50,7 +50,7 @@ SUBDIRS = . gtest util mapi/glapi/gen mapi
# include only conditionally ?
SUBDIRS += compiler
-if HAVE_GALLIUM_RADEON_COMMON
+if HAVE_AMD_DRIVERS
SUBDIRS += amd
endif
@@ -96,6 +96,11 @@ if HAVE_INTEL_VULKAN
SUBDIRS += intel/vulkan
endif
+if HAVE_RADEON_VULKAN
+SUBDIRS += amd/common
+SUBDIRS += amd/vulkan
+endif
+
if HAVE_GALLIUM
SUBDIRS += gallium
endif
--
2.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.
Re: [Mesa-dev] [PATCH 2/4] radv/winsys: import the amdgpu winsys for the radv vulkan driver.
First, I just wanted to say congrats and thanks for all the hard work
put into this! The implementation is very readable and written to a
pretty high standard already.
I just did a rather 'soft' review on this patch, there is a few trivial
style comments but one thing I noticed is a miss-aligned default in a
case statment.
Hope that helpful feedback otherwise this patch is then
Acked-by: Edward O'Callaghan
Though I will iterate a few more passes over the whole set over the next
few days.
Thanks again to you both.
Kind Regards,
Edward.
On 10/04/2016 12:48 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> This just brings these files into the tree, it doesn't integrate
> them with the build system.
>
> The radv winsys is based on the gallium one with some changes,
> due to how command buffers are built and lack of flushing behaviour.
>
> Authors: Bas Nieuwenhuizen and Dave Airlie
> Signed-off-by: Dave Airlie
> ---
> src/amd/vulkan/radv_radeon_winsys.h| 332 +
> src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c | 297
> src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.h | 50 ++
> src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c | 778
> +
> src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.h | 52 ++
> src/amd/vulkan/winsys/amdgpu/radv_amdgpu_surface.c | 523 ++
> src/amd/vulkan/winsys/amdgpu/radv_amdgpu_surface.h | 29 +
> src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.c | 359 ++
> src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.h | 32 +
> .../winsys/amdgpu/radv_amdgpu_winsys_public.h | 30 +
> 10 files changed, 2482 insertions(+)
> create mode 100644 src/amd/vulkan/radv_radeon_winsys.h
> create mode 100644 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c
> create mode 100644 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.h
> create mode 100644 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c
> create mode 100644 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.h
> create mode 100644 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_surface.c
> create mode 100644 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_surface.h
> create mode 100644 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.c
> create mode 100644 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.h
> create mode 100644 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys_public.h
>
> diff --git a/src/amd/vulkan/radv_radeon_winsys.h
> b/src/amd/vulkan/radv_radeon_winsys.h
> new file mode 100644
> index 000..1297583
> --- /dev/null
> +++ b/src/amd/vulkan/radv_radeon_winsys.h
> @@ -0,0 +1,332 @@
> +/*
> + * Copyright © 2016 Red Hat.
> + * Copyright © 2016 Bas Nieuwenhuizen
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> DEALINGS
> + * IN THE SOFTWARE.
> + */
> +#pragma once
> +
> +#include
> +#include
> +#include
> +#include "main/macros.h"
> +#include "ac_radeon_winsys.h"
> +
> +#define FREE(x) free(x)
> +
> +enum radeon_bo_domain { /* bitfield */
> + RADEON_DOMAIN_GTT = 2,
> + RADEON_DOMAIN_VRAM = 4,
> + RADEON_DOMAIN_VRAM_GTT = RADEON_DOMAIN_VRAM | RADEON_DOMAIN_GTT
> +};
> +
> +enum radeon_bo_flag { /* bitfield */
> + RADEON_FLAG_GTT_WC =(1 << 0),
> + RADEON_FLAG_CPU_ACCESS =(1 << 1),
> + RADEON_FLAG_NO_CPU_ACCESS = (1 << 2),
> +};
> +
> +enum radeon_bo_usage { /* bitfield */
> + RADEON_USAGE_READ = 2,
> + RADEON_USAGE_WRITE = 4,
> + RADEON_USAGE_READWRITE = RADEON_USAGE_READ | RADEON_USAGE_WRITE
> +};
> +
> +enum ring_type {
> + RING_GFX = 0,
> + RING_COMPUTE,
> + RING_DMA,
> + RING_UVD,
> + RING_VCE,
> + RING_LAST,
> +};
> +
> +struct radeon_winsys_cs {
> + unsigned cdw; /* Number of used dwords. */
> + unsigned max_dw; /* Maximum number of dwords. */
> + uint32_t *buf; /* The base pointer of the chunk. */
> +};
> +
> +struct radeon_info {
> + /* PCI info: domain:bus:dev:func */
> + uint32_t
Re: [Mesa-dev] [PATCH 4/4] radv: toplevel configure/make changes required to build
Reviewed-by: Edward O'Callaghan
On 10/04/2016 12:48 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> This moves some of the llvm checks around to allow them
> to be used for non-gallium drivers as well.
>
> radv requires llvm 3.9.0 as vulkan requires compute shaders.
>
> Authors: Bas Nieuwenhuizen and Dave Airlie
> Signed-off-by: Dave Airlie
> ---
> configure.ac| 33 ++---
> src/Makefile.am | 7 ++-
> 2 files changed, 32 insertions(+), 8 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 1bfac3b..634f3c3 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1704,6 +1704,10 @@ if test -n "$with_vulkan_drivers"; then
> HAVE_INTEL_VULKAN=yes;
>
> ;;
> +xradeon)
> +PKG_CHECK_MODULES([AMDGPU], [libdrm_amdgpu >=
> $LIBDRM_AMDGPU_REQUIRED])
> +HAVE_RADEON_VULKAN=yes;
> + ;;
> *)
> AC_MSG_ERROR([Vulkan driver '$driver' does not exist])
> ;;
> @@ -2187,7 +2191,7 @@ if test "x$enable_gallium_llvm" = xauto; then
> i*86|x86_64|amd64) enable_gallium_llvm=yes;;
> esac
> fi
> -if test "x$enable_gallium_llvm" = xyes; then
> +if test "x$enable_gallium_llvm" = xyes || test "x$HAVE_RADEON_VULKAN" =
> xyes; then
> if test -n "$llvm_prefix"; then
> AC_PATH_TOOL([LLVM_CONFIG], [llvm-config], [no],
> ["$llvm_prefix/bin"])
> else
> @@ -2357,10 +2361,7 @@ radeon_llvm_check() {
> else
> amdgpu_llvm_target_name='amdgpu'
> fi
> -if test "x$enable_gallium_llvm" != "xyes"; then
> -AC_MSG_ERROR([--enable-gallium-llvm is required when building $1])
> -fi
> -llvm_check_version_for "3" "6" "0" $1
> +llvm_check_version_for $2 $3 $4 $1
> if test true && $LLVM_CONFIG --targets-built | grep -iqvw
> $amdgpu_llvm_target_name ; then
> AC_MSG_ERROR([LLVM $amdgpu_llvm_target_name not enabled in your LLVM
> build.])
> fi
> @@ -2371,6 +2372,13 @@ radeon_llvm_check() {
> fi
> }
>
> +radeon_gallium_llvm_check() {
> +if test "x$enable_gallium_llvm" != "xyes"; then
> +AC_MSG_ERROR([--enable-gallium-llvm is required when building $1])
> +fi
> +radeon_llvm_check $*
> +}
> +
> swr_llvm_check() {
> gallium_require_llvm $1
> if test ${LLVM_VERSION_INT} -lt 306; then
> @@ -2455,7 +2463,7 @@ if test -n "$with_gallium_drivers"; then
> gallium_require_drm "Gallium R600"
> gallium_require_drm_loader
> if test "x$enable_opencl" = xyes; then
> -radeon_llvm_check "r600g"
> +radeon_gallium_llvm_check "r600g" "3" "6" "0"
> LLVM_COMPONENTS="${LLVM_COMPONENTS} bitreader asmparser"
> fi
> ;;
> @@ -2465,7 +2473,7 @@ if test -n "$with_gallium_drivers"; then
> PKG_CHECK_MODULES([AMDGPU], [libdrm_amdgpu >=
> $LIBDRM_AMDGPU_REQUIRED])
> gallium_require_drm "radeonsi"
> gallium_require_drm_loader
> -radeon_llvm_check "radeonsi"
> +radeon_gallium_llvm_check "radeonsi" "3" "6" "0"
> require_egl_drm "radeonsi"
> ;;
> xnouveau)
> @@ -2584,6 +2592,10 @@ if test "x$MESA_LLVM" != x0; then
> fi
> fi
>
> +if test "x$HAVE_RADEON_VULKAN" != "x0"; then
> +radeon_llvm_check "radv" "3" "9" "0"
> +fi
> +
> AM_CONDITIONAL(HAVE_GALLIUM_SVGA, test "x$HAVE_GALLIUM_SVGA" = xyes)
> AM_CONDITIONAL(HAVE_GALLIUM_I915, test "x$HAVE_GALLIUM_I915" = xyes)
> AM_CONDITIONAL(HAVE_GALLIUM_ILO, test "x$HAVE_GALLIUM_ILO" = xyes)
> @@ -2621,8 +2633,13 @@ AM_CONDITIONAL(HAVE_R200_DRI, test x$HAVE_R200_DRI =
> xyes)
> AM_CONDITIONAL(HAVE_RADEON_DRI, test x$HAVE_RADEON_DRI = xyes)
> AM_CONDITIONAL(HAVE_SWRAST_DRI, test x$HAVE_SWRAST_DRI = xyes)
>
> +AM_CONDITIONAL(HAVE_RADEON_VULKAN, test "x$HAVE_RADEON_VULKAN" = xyes)
> AM_CONDITIONAL(HAVE_INTEL_VULKAN, test "x$HAVE_INTEL_VULKAN" = xyes)
>
> +AM_CONDITIONAL(HAVE_AMD_DRIVERS, test "x$HAVE_GALLIUM_R600" = xyes -o \
> + "x$HAVE_GALLIUM_RADEONSI" = xyes -o \
> + "x$HAVE_RADEON_VULKAN" = xyes)
> +
> AM_CONDITIONAL(HAVE_INTEL_DRIVERS, test "x$HAVE_INTEL_VULKAN" = xyes -o \
> "x$HAVE_I965_DRI" = xyes)
>
> @@ -2713,6 +2730,8 @@ dnl Substitute the config
> AC_CONFIG_FILES([Makefile
> src/Makefile
> src/amd/Makefile
> + src/amd/common/Makefile
> + src/amd/vulkan/Makefile
> src/compiler/Makefile
> src/egl/Makefile
> src/egl/main/egl.pc
> diff --git a/src/Makefile.am b/src/Makefile.am
> index 551f431..6a35f19 100644
> --- a/src/Makefile.am
> +++ b/src/Makefile.am
> @@ -50,7 +50,7 @@ SUBDIRS = . gtest util mapi/glapi/gen mapi
> # include only conditionally ?
> SUBDIRS += compiler
>
> -if HAVE_GALLIUM_RADEON_COMMON
> +if HAVE_AMD_DRIVERS
>
Re: [Mesa-dev] [PATCH] spirv: replace assert() with unreachable()
Reviewed-by: Jason Ekstrand
On Mon, Oct 3, 2016 at 5:25 PM, Timothy Arceri wrote:
> This fixes an uninitialized warning for is_vertex_input.
> ---
> src/compiler/spirv/vtn_variables.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/compiler/spirv/vtn_variables.c b/src/compiler/spirv/vtn_
> variables.c
> index 43bb3bc..f431c6f 100644
> --- a/src/compiler/spirv/vtn_variables.c
> +++ b/src/compiler/spirv/vtn_variables.c
> @@ -1054,7 +1054,7 @@ var_decoration_cb(struct vtn_builder *b, struct
> vtn_value *val, int member,
> is_vertex_input = false;
> location += VARYING_SLOT_VAR0;
>} else {
> - assert(!"Location must be on input or output variable");
> + unreachable("Location must be on input or output variable");
>}
>
>if (vtn_var->var) {
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Proposal of date-based Mesa versioning for 2017
Yeah I think the value of having a date based system is to quickly check when the release was made, dayoutofdaysthatyear isn't really providing any extra benefit since its hard to read and that extra info is probably rather pointless for quick fix releases since the mesa-dev branch and a quick fix release wouldn't be syncronised (which also could cause confusion). I also don't think people are really going to have a problem with skipped version numbers anyway (at least not one of concern). I think its best to just ignore that and do what is best for the future. So yes, dayoutofdaysthatyear is a detrimental system. Though I also think that keeping to a quaterly release schedule is a bad idea. Probably better to try to pick all the dates which align best with major distros and/or release when something of major value gets developed. What matters more: sticking to a schedule that fits seasons of the year just because humans feel like it, or getting features out to users as quickly as possible. If releases only happen 3 times a year some years then it will just create confusion if people are trying to interpret minor versions as quaterly periods, you would have to remember which years are quaterly. Though I am just trying to help, I personally don't care what release system is chosen, so you need not take my opinion into consideration. On 3 October 2016 at 09:40, Jason Ekstrand wrote: > > On Oct 3, 2016 12:19 AM, "Albert Freeman" wrote: >> >> year.month or year.dayoutofdaysthatyear > > Why are we adding more options to an already confused discussion? > >> dayoutoofdaysthatyear skips lots of integers quickly: reducing >> confusion of where is release x.(y - something) and better handles >> quick fix releases >> but makes it harder to determine how far into the year the release is >> although with some effort can be converted into an exact date > > Quick fix releases are already handled by the stable release system which I > don't think anyone is recommending we get rid of. Also, I haven't heard > anyone complain that year.quarter (really, year.releaseofyear) isn't > shipping enough integers. I don't see what problem your suggestion is > solving. > >> On 2 October 2016 at 14:22, Tobias Klausmann >> wrote: >> > >> > >> > On 02.10.2016 13:56, Nicolai Hähnle wrote: >> >> >> >> On 01.10.2016 22:22, Tobias Klausmann wrote: >> >>> >> >>> On 01.10.2016 21:46, Marek Olšák wrote: >> >> Hi, >> >> I propose that we use versioning in the form of "year.quarter". >> >> 2017 would start with 17.0, then 17.1, 17.2, 17.3 for following >> quarters of the year, respectively. >> 2018 would start with 18.0, then 18.1, 18.2, 18.3. >> >> The motivation is that you can easily tell when a specific Mesa >> version was released with an accuracy of 3 months. >> >> That's the only scheme that seems practical to me. Everything else >> seems arbitrary or random. >> >> Opinions? >> >>> >> >>> >> >>> Why not just use year.month instead, would be more accurate...and >> >>> releases happen semi random anyway and not after a given time. >> >> >> >> >> >> That's fine for something like Ubuntu where they really stick to their >> >> two >> >> releases per year, in the same months each year. I'm not so sure that >> >> that's >> >> a realistic goal for Mesa, and if releases *aren't* consistently >> >> happening >> >> in the same months, you end up introducing a lot of confusion about >> >> which >> >> version numbers exist and which don't. >> > >> > >> > This is true, but also holds true for year.quarter, if we miss one >> > quarterly >> > release (18.1, 18.2, 18.4, whoops where is 18.3). >> > >> >> >> >> Time-based with YY.0 for the first release of the year, and then YY.1, >> >> YY.2, etc. works fine. >> > >> > >> > Thats allright and would help in not confuse people so much, but with it >> > you >> > miss the "when was it released again?" thing Marek tried to introduce. >> > >> > Greetings, >> > Tobias >> > >> > >> >> >> >> Cheers, >> >> Nicolai >> > >> > >> > ___ >> > mesa-dev mailing list >> > mesa-dev@lists.freedesktop.org >> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev >> ___ >> mesa-dev mailing list >> mesa-dev@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 7/8] i965: Drop _NEW_TRANSFORM from 3DSTATE_VS atom on Gen6-7.
On Wed, Sep 21, 2016 at 10:31 PM, Kenneth Graunke
wrote:
> commit e07457d0aec96970a39a2dd1cb4e46da6107eb77 removed the last use
> of ctx->Transform on Gen6. It looks like Gen7 never needed this, but
>
Not so much... The mentioned commit actually contains a very nice comment
specifying why NEW_TRANSFORM is needed. On gen6, some elements of
prog_data->param may refer to user clip planes so we need to re-upload push
constants whenever we get NEW_TRANSFORM.
Not sure what the implications are for IVB.
> I copied it over when I originally ported the driver to Ivybridge.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/gen6_vs_state.c | 3 +--
> src/mesa/drivers/dri/i965/gen7_vs_state.c | 2 +-
> 2 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/gen6_vs_state.c
> b/src/mesa/drivers/dri/i965/gen6_vs_state.c
> index 5446ef9..849fff9 100644
> --- a/src/mesa/drivers/dri/i965/gen6_vs_state.c
> +++ b/src/mesa/drivers/dri/i965/gen6_vs_state.c
> @@ -60,8 +60,7 @@ gen6_upload_vs_push_constants(struct brw_context *brw)
>
> const struct brw_tracked_state gen6_vs_push_constants = {
> .dirty = {
> - .mesa = _NEW_PROGRAM_CONSTANTS |
> - _NEW_TRANSFORM,
> + .mesa = _NEW_PROGRAM_CONSTANTS,
>.brw = BRW_NEW_BATCH |
> BRW_NEW_BLORP |
> BRW_NEW_PUSH_CONSTANT_ALLOCATION |
> diff --git a/src/mesa/drivers/dri/i965/gen7_vs_state.c
> b/src/mesa/drivers/dri/i965/gen7_vs_state.c
> index 2715b37..7daa018 100644
> --- a/src/mesa/drivers/dri/i965/gen7_vs_state.c
> +++ b/src/mesa/drivers/dri/i965/gen7_vs_state.c
> @@ -74,7 +74,7 @@ upload_vs_state(struct brw_context *brw)
>
> const struct brw_tracked_state gen7_vs_state = {
> .dirty = {
> - .mesa = _NEW_TRANSFORM,
> + .mesa = 0,
>.brw = BRW_NEW_BATCH |
> BRW_NEW_BLORP |
> BRW_NEW_CONTEXT |
> --
> 2.10.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 6/8] i965: Add missing BRW_CS_PROG_DATA to CS work group surface atom.
1-6 are
Reviewed-by: Jason Ekstrand
I think Nanley had a typo fix on 1 that you should probably take care of.
On Wed, Sep 21, 2016 at 10:31 PM, Kenneth Graunke
wrote:
> Cc: mesa-sta...@lists.freedesktop.org
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> index 7b5e380..834e8f2 100644
> --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> +++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> @@ -1840,10 +1840,12 @@ brw_upload_cs_work_groups_surface(struct
> brw_context *brw)
> /* _NEW_PROGRAM */
> struct gl_shader_program *prog =
>ctx->_Shader->CurrentProgram[MESA_SHADER_COMPUTE];
> + /* BRW_NEW_CS_PROG_DATA */
> + const struct brw_cs_prog_data *cs_prog_data = brw->cs.prog_data;
>
> - if (prog && brw->cs.prog_data->uses_num_work_groups) {
> + if (prog && cs_prog_data->uses_num_work_groups) {
>const unsigned surf_idx =
> - brw->cs.prog_data->binding_table.work_groups_start;
> + cs_prog_data->binding_table.work_groups_start;
>uint32_t *surf_offset = &brw->cs.base.surf_offset[surf_idx];
>drm_intel_bo *bo;
>uint32_t bo_offset;
> @@ -1872,6 +1874,7 @@ brw_upload_cs_work_groups_surface(struct
> brw_context *brw)
> const struct brw_tracked_state brw_cs_work_groups_surface = {
> .dirty = {
>.brw = BRW_NEW_BLORP |
> + BRW_NEW_CS_PROG_DATA |
> BRW_NEW_CS_WORK_GROUPS
> },
> .emit = brw_upload_cs_work_groups_surface,
> --
> 2.10.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 7/8] i965: Drop _NEW_TRANSFORM from 3DSTATE_VS atom on Gen7.
The atom that uploads push constants listens to _NEW_TRANSFORM for
legacy clip plane handling. On Sandybridge, the gen6_vs_state atom
emits 3DSTATE_CONSTANT_VS as well as 3DSTATE_VS, so it needs to listen
to the same set of conditions.
However, it looks like Gen7 doesn't need this. The push constant atom
emits 3DSTATE_CONSTANT_VS directly, and the gen7_vs_state atom that
emits 3DSTATE_VS doesn't have a dependency on ctx->Transform.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/gen7_vs_state.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Whoops :( I meant to remove it from gen6_vs_state, not the push constant
atom...and frankly, even that's not right. Thanks for catching that.
Here's a v2 that just changes Ivybridge.
diff --git a/src/mesa/drivers/dri/i965/gen7_vs_state.c
b/src/mesa/drivers/dri/i965/gen7_vs_state.c
index 57e0419..cfd535e 100644
--- a/src/mesa/drivers/dri/i965/gen7_vs_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_vs_state.c
@@ -75,7 +75,7 @@ upload_vs_state(struct brw_context *brw)
const struct brw_tracked_state gen7_vs_state = {
.dirty = {
- .mesa = _NEW_TRANSFORM,
+ .mesa = 0,
.brw = BRW_NEW_BATCH |
BRW_NEW_BLORP |
BRW_NEW_CONTEXT |
--
2.10.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 7/8] i965: Drop _NEW_TRANSFORM from 3DSTATE_VS atom on Gen7.
rb
On Mon, Oct 3, 2016 at 9:41 PM, Kenneth Graunke
wrote:
> The atom that uploads push constants listens to _NEW_TRANSFORM for
> legacy clip plane handling. On Sandybridge, the gen6_vs_state atom
> emits 3DSTATE_CONSTANT_VS as well as 3DSTATE_VS, so it needs to listen
> to the same set of conditions.
>
> However, it looks like Gen7 doesn't need this. The push constant atom
> emits 3DSTATE_CONSTANT_VS directly, and the gen7_vs_state atom that
> emits 3DSTATE_VS doesn't have a dependency on ctx->Transform.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/gen7_vs_state.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Whoops :( I meant to remove it from gen6_vs_state, not the push constant
> atom...and frankly, even that's not right. Thanks for catching that.
>
> Here's a v2 that just changes Ivybridge.
>
> diff --git a/src/mesa/drivers/dri/i965/gen7_vs_state.c
> b/src/mesa/drivers/dri/i965/gen7_vs_state.c
> index 57e0419..cfd535e 100644
> --- a/src/mesa/drivers/dri/i965/gen7_vs_state.c
> +++ b/src/mesa/drivers/dri/i965/gen7_vs_state.c
> @@ -75,7 +75,7 @@ upload_vs_state(struct brw_context *brw)
>
> const struct brw_tracked_state gen7_vs_state = {
> .dirty = {
> - .mesa = _NEW_TRANSFORM,
> + .mesa = 0,
>.brw = BRW_NEW_BATCH |
> BRW_NEW_BLORP |
> BRW_NEW_CONTEXT |
> --
> 2.10.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
