Re: [Mesa-dev] Question about display_gpu and render gpu in dri3_create_screen

Mhm, that looks like it's something I should look into. How exactly are you triggering this and which kernel version are you using? Thanks, Christian. Am 14.09.21 um 03:47 schrieb Luc Ma: Yes, I did. It crashed the kernel as follows Sep 14 09:12:34 kernel: [  506.676925][ 4] [ T1045] Hardware

Re: [Mesa-dev] Question about display_gpu and render gpu in dri3_create_screen

Yes, I did. It crashed the kernel as follows Sep 14 09:12:34 kernel: [ 506.676925][ 4] [ T1045] Hardware name: WEIBU F20A8/F20A8, BIOS 0.1.3 2021-07-06_20:59:09 Sep 14 09:12:34 kernel: [ 506.685091][ 4] [ T1045] pstate: 8005 (Nzcv daif -PAN -UAO) Sep 14 09:12:34 kernel: [ 506.691001][ 4] [

Re: [Mesa-dev] Question about display_gpu and render gpu in dri3_create_screen

On 2021-09-13 14:40, Luc Ma wrote: > Hello, > > I recently tried multi-GPU support on the mesa gallium drivers(glx=dri). When > I exported the env `DRI_PRIME=1`, I found that it didn't work with two > different drivers loaded at the same time. > because there are different driver names in my cas

[Mesa-dev] Question about display_gpu and render gpu in dri3_create_screen

Hello, I recently tried multi-GPU support on the mesa gallium drivers(glx=dri). When I exported the env `DRI_PRIME=1`, I found that it didn't work with two different drivers loaded at the same time. because there are different driver names in my case. display_gpu driver name is "r600" while render

[Mesa-dev] Question in wsi_common_x11.c

Hello, In the following code why mage->base.row_pitches[0] is divided by 4 and passed as width to xcb_put_function() ? 26 static VkResult 25 x11_present_to_x11_sw(struct x11_swapchain *chain, uint32_t image_index, ... 15 14cookie = xcb_put_image(chain->conn, XCB_IMAGE_FORMAT_Z_PIXMAP,

Re: [Mesa-dev] question about MR8409 status

On 2/2/21 2:47 pm, Lionel Landwerlin wrote: Hi Andrii, Just assigned it to Marge. Sorry for the delay. Thanks a lot. -Lionel On 02/02/2021 13:57, asimiklit wrote: Hello, Are there some issues/blockers which prevent MR8409 from being merged? This MR already has r-b and I suspect that it w

Re: [Mesa-dev] question about MR8409 status

Hi Andrii, Just assigned it to Marge. Sorry for the delay. -Lionel On 02/02/2021 13:57, asimiklit wrote: Hello, Are there some issues/blockers which prevent MR8409 from being merged? This MR already has r-b and I suspect that it was simply forgotten or there are some issues with it I am not

[Mesa-dev] question about MR8409 status

Hello, Are there some issues/blockers which prevent MR8409 from being merged? This MR already has r-b and I suspect that it was simply forgotten or there are some issues with it I am not aware of. I don't have merge access that is why I am asking about it. Thanks, Andrii. __

Re: [Mesa-dev] Question on ~/mesa/src/amd/llvm/ac_nir_to_llvm.c visit_load_var

Hi, I'd like to complement Jason's excellent answer with some code examples. ac_nir_to_llvm is used by two drivers, RADV and RadeonSI. Each of them have a driver-specific implementation of the shader ABI. For RADV's implementation, take a look at llvm_compile_shader in radv_nir_to_llvm.c and to

Re: [Mesa-dev] Question on ~/mesa/src/amd/llvm/ac_nir_to_llvm.c visit_load_var

Possibly worth noting as another point for reference is that zink also uses variables. On Sun, Oct 11, 2020, 11:08 AM Jason Ekstrand wrote: > First off, I should point out that the AMD NIR -> LLVM translator is, > as far as I know, the only NIR back-end that consumes variables at > all. Most ba

Re: [Mesa-dev] Question on ~/mesa/src/amd/llvm/ac_nir_to_llvm.c visit_load_var

First off, I should point out that the AMD NIR -> LLVM translator is, as far as I know, the only NIR back-end that consumes variables at all. Most back-ends assume that all variable access is completely lowered away before the back-end ever sees it. How this is done depends on the variable mode.

[Mesa-dev] Question on ~/mesa/src/amd/llvm/ac_nir_to_llvm.c visit_load_var

I see that visit_load_var() in ~/mesa/src/amd/llvm/ac_nir_to_llvm.c assumes that nir_variable used in this intrinsic can have few specific mods only. For example variable can not have nir_var_mem_shared , if such mod encountered it will execute unreachable() code. Is there any nir pass that need

[Mesa-dev] [Question] nir_intrinsic_load_uniform use float const_offset now

Hi guys, When doing rebase from 18.3 to master branch, I found nir_intrinsic_load_uniform use float const_offset now. But most gallium drivers still treat it as int except freedreno. I don't know which commit did this, is this expected? Regards, Qiang

Re: [Mesa-dev] Question about EGL_KHR_partial_update implementation

Hi Frank, On 28 June 2018 at 11:12, Frank Binns wrote: > Hi Qiang, > > Qiang Yu writes: > >> Hi Harish, >> >> I want to implement EGL_KHR_partial_update for lima mesa driver and find you >> worked on Android/Wayland support for it: >> https://patchwork.freedesktop.org/patch/160944/ >> https://pa

Re: [Mesa-dev] Question about EGL_KHR_partial_update implementation

Hi Qiang, Qiang Yu writes: >> > For lima implementation, I want to use the damage region (buffer >> > damage) provided >> > by EGL_KHR_partial_update to skip rendering of un-damaged region when >> > eglSwapBuffersXXX. And tell damage region (surface damage) to compositor >> > should >> > be lef

Re: [Mesa-dev] Question about EGL_KHR_partial_update implementation

Hi Harish, > > > To my understand this extension should only depend on the driver support > > instead > > of platform support while the EGL_KHR_swap_buffers_with_damage is the > > opposite: > > https://www.khronos.org/registry/EGL/extensions/KHR/EGL_KHR_swap_buffers_with_damage.txt > > > > I alw

Re: [Mesa-dev] Question about EGL_KHR_partial_update implementation

Hi Qiang, Thanks for probing about this. Qiang Yu writes: > Hi Harish, > > I want to implement EGL_KHR_partial_update for lima mesa driver and find you > worked on Android/Wayland support for it: > https://patchwork.freedesktop.org/patch/160944/ > https://patchwork.freedesktop.org/patch/188695/

Re: [Mesa-dev] Question about EGL_KHR_partial_update implementation

Hi Qiang, Qiang Yu writes: > Hi Harish, > > I want to implement EGL_KHR_partial_update for lima mesa driver and find you > worked on Android/Wayland support for it: > https://patchwork.freedesktop.org/patch/160944/ > https://patchwork.freedesktop.org/patch/188695/ > > So I have some question abo

[Mesa-dev] Question about EGL_KHR_partial_update implementation

Hi Harish, I want to implement EGL_KHR_partial_update for lima mesa driver and find you worked on Android/Wayland support for it: https://patchwork.freedesktop.org/patch/160944/ https://patchwork.freedesktop.org/patch/188695/ So I have some question about it: your implementation seems to depend o

Re: [Mesa-dev] Question about NIR changes since mesa 17.3

On 31/03/18 00:43, Qiang Yu wrote: Hi guys, I'm rebasing the mesa-lima code from 17.3 to 18.0 and found the NIR changes in 18.0 will always do nir_lower_io_to_scalar_early() for the output of vertex shader and input of fragment shader. My first question is: Is it for the link time optimization

[Mesa-dev] Question about NIR changes since mesa 17.3

Hi guys, I'm rebasing the mesa-lima code from 17.3 to 18.0 and found the NIR changes in 18.0 will always do nir_lower_io_to_scalar_early() for the output of vertex shader and input of fragment shader. My first question is: Is it for the link time optimization that we can drop un-used channel in a

Re: [Mesa-dev] Question about min_index/max_index calculation

On Mon, Mar 26, 2018 at 6:39 PM, Erico Nunes wrote: > Thanks all for the input. > > I don't have an in-depth knowledge of the hardware either, though as > far as we can see the hardware does expect that we pass min_index in > the command stream. max_index is used to calculate the sizes in other >

Re: [Mesa-dev] Question about min_index/max_index calculation

Thanks all for the input. I don't have an in-depth knowledge of the hardware either, though as far as we can see the hardware does expect that we pass min_index in the command stream. max_index is used to calculate the sizes in other command stream fields (which is not the same as pipe_draw_info.c

Re: [Mesa-dev] Question about min_index/max_index calculation

On Sat, Mar 24, 2018 at 6:00 PM, Jason Ekstrand wrote: > On Sat, Mar 24, 2018 at 2:27 PM, Marek Olšák wrote: >> >> On Sat, Mar 24, 2018 at 1:36 PM, Connor Abbott >> wrote: >>> >>> If Gallium was being lazy and not >>> specifying the bounds for internal shaders, that needs to be fixed for >>> the

Re: [Mesa-dev] Question about min_index/max_index calculation

On Sat, Mar 24, 2018 at 2:27 PM, Marek Olšák wrote: > On Sat, Mar 24, 2018 at 1:36 PM, Connor Abbott > wrote: > >> If Gallium was being lazy and not >> specifying the bounds for internal shaders, that needs to be fixed for >> the HW to work properly. >> > > I don't understand the sentence. Shade

Re: [Mesa-dev] Question about min_index/max_index calculation

On Sat, Mar 24, 2018 at 5:27 PM, Marek Olšák wrote: > On Sat, Mar 24, 2018 at 1:36 PM, Connor Abbott > wrote: > >> If Gallium was being lazy and not >> specifying the bounds for internal shaders, that needs to be fixed for >> the HW to work properly. >> > > I don't understand the sentence. Shade

Re: [Mesa-dev] Question about min_index/max_index calculation

On Sat, Mar 24, 2018 at 1:36 PM, Connor Abbott wrote: > If Gallium was being lazy and not > specifying the bounds for internal shaders, that needs to be fixed for > the HW to work properly. > I don't understand the sentence. Shaders don't interact with vertex indices. I also don't like the word

Re: [Mesa-dev] Question about min_index/max_index calculation

My understanding is that unlike most other architectures, Mali does vertex shading on every vertex up-front, completely ignoring the index buffer. Primitive assembly and tile binning happen after every vertex is transformed. There is no cache of transformed vertices. Utgard also only supports GLES2

Re: [Mesa-dev] Question about min_index/max_index calculation

The index bounds are computed only when they are needed for uploading vertices that are passed via a CPU pointer (user_buffer). In all other cases, computing the index bounds has a performance cost, which can be very significant. If you rely on u_vbuf to upload vertices for you, you shouldn't need

Re: [Mesa-dev] Question about min_index/max_index calculation

On Sat, Mar 17, 2018 at 2:12 PM, Erico Nunes wrote: > Hi all, > > I have been working to add indexed drawing/glDrawElements support to > the mesa-lima driver currently in development > (https://github.com/yuq/mesa-lima). > For that implementation, it seems that we need to have the minimum and > ma

[Mesa-dev] Question about min_index/max_index calculation

Hi all, I have been working to add indexed drawing/glDrawElements support to the mesa-lima driver currently in development (https://github.com/yuq/mesa-lima). For that implementation, it seems that we need to have the minimum and maximum index values from the index buffer available in order to set

[Mesa-dev] Question: Underutilization of GPU in certain benchmarks - Bug or Feature ?

Hi all, while looking for problems with NIR, I noticed that in the Bioshock Infinite and also Dirt Rallye Benchmark there are times when GPU shader utilization drops to 80% (Bioshock) or 60% (Dirt Rallye). In Bioshock this directly associated with fps drops, in Dirt Rallye it is not so obvious bu

Re: [Mesa-dev] Question about implementing viewport transfer and const load in nir

On 30.08.2017 16:44, Rob Clark wrote: On Wed, Aug 30, 2017 at 10:18 AM, Qiang Yu wrote: On Wed, Aug 30, 2017 at 9:03 PM, Rob Clark wrote: On Wed, Aug 30, 2017 at 3:26 AM, Qiang Yu wrote: btw, does lima have some way to write to memory from cmdstream (ie. without setting up a full blown draw

Re: [Mesa-dev] Question about implementing viewport transfer and const load in nir

On Wed, Aug 30, 2017 at 10:18 AM, Qiang Yu wrote: > On Wed, Aug 30, 2017 at 9:03 PM, Rob Clark wrote: >> On Wed, Aug 30, 2017 at 3:26 AM, Qiang Yu wrote: btw, does lima have some way to write to memory from cmdstream (ie. without setting up a full blown draw)? If so perhaps you could

Re: [Mesa-dev] Question about implementing viewport transfer and const load in nir

On Wed, Aug 30, 2017 at 9:03 PM, Rob Clark wrote: > On Wed, Aug 30, 2017 at 3:26 AM, Qiang Yu wrote: >>> btw, does lima have some way to write to memory from cmdstream (ie. >>> without setting up a full blown draw)? If so perhaps you could get >>> away with leaving some extra space at the end of

Re: [Mesa-dev] Question about implementing viewport transfer and const load in nir

On Wed, Aug 30, 2017 at 3:26 AM, Qiang Yu wrote: >> btw, does lima have some way to write to memory from cmdstream (ie. >> without setting up a full blown draw)? If so perhaps you could get >> away with leaving some extra space at the end of your uniform buffer >> that you copy driver internal un

Re: [Mesa-dev] Question about implementing viewport transfer and const load in nir

> btw, does lima have some way to write to memory from cmdstream (ie. > without setting up a full blown draw)? If so perhaps you could get > away with leaving some extra space at the end of your uniform buffer > that you copy driver internal uniforms into before kicking the draw? Unfortunately lim

Re: [Mesa-dev] Question about implementing viewport transfer and const load in nir

> In my case, VC4 has lots of custom state-dependent uniforms, and uniform > upload is where we spend most of our CPU time (basically each draw call > needs to re-upload the uniform stream, and the stream has to be in the > order they will be used by instructions, rather than where they appear > in

Re: [Mesa-dev] Question about implementing viewport transfer and const load in nir

Thanks Kenneth, here attach my RFC prototype patch implementing these, and comments follows. >> When working on lima gp compiler, I come across two problems about >> inserting extra uniform >> and instructions in nir for the driver and don't know where's the >> right place to do it. So I'd like >>

Re: [Mesa-dev] Question about implementing viewport transfer and const load in nir

On Sat, Aug 26, 2017 at 9:40 AM, Qiang Yu wrote: > Hi guys, > > When working on lima gp compiler, I come across two problems about > inserting extra uniform > and instructions in nir for the driver and don't know where's the > right place to do it. So I'd like > to hear your opinion and if there's

Re: [Mesa-dev] Question about implementing viewport transfer and const load in nir

Kenneth Graunke writes: > [ Unknown signature status ] > On Saturday, August 26, 2017 6:40:14 AM PDT Qiang Yu wrote: >> Hi guys, >> >> When working on lima gp compiler, I come across two problems about >> inserting extra uniform >> and instructions in nir for the driver and don't know where's th

Re: [Mesa-dev] Question about implementing viewport transfer and const load in nir

On Saturday, August 26, 2017 6:40:14 AM PDT Qiang Yu wrote: > Hi guys, > > When working on lima gp compiler, I come across two problems about > inserting extra uniform > and instructions in nir for the driver and don't know where's the > right place to do it. So I'd like > to hear your opinion and

[Mesa-dev] Question about implementing viewport transfer and const load in nir

Hi guys, When working on lima gp compiler, I come across two problems about inserting extra uniform and instructions in nir for the driver and don't know where's the right place to do it. So I'd like to hear your opinion and if there's other driver already did so. 1. viewport transfer lima gp nee

Re: [Mesa-dev] Question for nir lower load uniform to scalar

On Sat, Aug 26, 2017 at 3:07 AM, Eric Anholt wrote: > Qiang Yu writes: > >> Hi Eric, >> >> I'm working on lima gp compiler which should benefit from nir lowering >> uniform load to scalar. >> I notice you write the nir_lower_io_to_scalar.c which support lowering >> shader_in/shader_out >> but lef

Re: [Mesa-dev] Question for nir lower load uniform to scalar

On August 25, 2017 12:14:20 PM Eric Anholt wrote: Qiang Yu writes: Hi Eric, I'm working on lima gp compiler which should benefit from nir lowering uniform load to scalar. I notice you write the nir_lower_io_to_scalar.c which support lowering shader_in/shader_out but left the uniform lowerin

Re: [Mesa-dev] Question for nir lower load uniform to scalar

Qiang Yu writes: > Hi Eric, > > I'm working on lima gp compiler which should benefit from nir lowering > uniform load to scalar. > I notice you write the nir_lower_io_to_scalar.c which support lowering > shader_in/shader_out > but left the uniform lowering in vc4 driver, any reason why not > impl

[Mesa-dev] Question for nir lower load uniform to scalar

Hi Eric, I'm working on lima gp compiler which should benefit from nir lowering uniform load to scalar. I notice you write the nir_lower_io_to_scalar.c which support lowering shader_in/shader_out but left the uniform lowering in vc4 driver, any reason why not implement in the nir_lower_io_to_scala

Re: [Mesa-dev] question about container_of

On 20.04.2017 18:32, Emil Velikov wrote: On 18 April 2017 at 13:55, Pekka Paalanen wrote: On Mon, 27 Feb 2017 13:26:11 + Emil Velikov wrote: Hi Julien, On 27 February 2017 at 12:08, Julien Isorce wrote: Hi, Since 2012 commit ccff74971203b533bf16b46b49a9e61753f75e6c it is said: "sampl

Re: [Mesa-dev] question about container_of

Emil Velikov writes: > On 18 April 2017 at 13:55, Pekka Paalanen wrote: >> On Mon, 27 Feb 2017 13:26:11 + >> Emil Velikov wrote: >> >>> Hi Julien, >>> >>> On 27 February 2017 at 12:08, Julien Isorce wrote: >>> > Hi, >>> > >>> > Since 2012 commit ccff74971203b533bf16b46b49a9e61753f75e6c it

Re: [Mesa-dev] question about container_of

On 18 April 2017 at 13:55, Pekka Paalanen wrote: > On Mon, 27 Feb 2017 13:26:11 + > Emil Velikov wrote: > >> Hi Julien, >> >> On 27 February 2017 at 12:08, Julien Isorce wrote: >> > Hi, >> > >> > Since 2012 commit ccff74971203b533bf16b46b49a9e61753f75e6c it is said: >> > "sample must be init

Re: [Mesa-dev] question about container_of

On Mon, 27 Feb 2017 13:26:11 + Emil Velikov wrote: > Hi Julien, > > On 27 February 2017 at 12:08, Julien Isorce wrote: > > Hi, > > > > Since 2012 commit ccff74971203b533bf16b46b49a9e61753f75e6c it is said: > > "sample must be initialized, or else the result is undefined" in the > > descript

Re: [Mesa-dev] question about container_of

Hi Julien, On 27 February 2017 at 12:08, Julien Isorce wrote: > Hi, > > Since 2012 commit ccff74971203b533bf16b46b49a9e61753f75e6c it is said: > "sample must be initialized, or else the result is undefined" in the > description of mesa/src/util/list.h::container_of . > > But I can find a few plac

[Mesa-dev] question about container_of

Hi, Since 2012 commit ccff74971203b533bf16b46b49a9e61753f75e6c it is said: "sample must be initialized, or else the result is undefined" in the description of mesa/src/util/list.h::container_of . But I can find a few places where it is used without initializing that second parameter, i.e. like:

[Mesa-dev] Question: How to handle 64-bit sampler/image handles added by ARB_bindless_texture?

Hi there, I started to work on ARB_bindless_texture which is an important missing feature in Mesa. Some games, at least Deus Ex: Mankind Divided, would benefit of this extension. As the spec says: "The ability to access textures without having to bind and/or re-bind them is similar to the cap

Re: [Mesa-dev] Question about handling RGBA/BGRA in etnaviv driver

> > Another way that I just realized would be to convert a texture to BGRA the > > first time it's rendered to. > > > > In contrast to the shader solution that has only a one-time overhead. Is > > this a stupid idea for any reason? > We are doing something similar to convert sampled textures to t

Re: [Mesa-dev] Question about handling RGBA/BGRA in etnaviv driver

On Fri, Feb 3, 2017 at 11:06 AM, Wladimir wrote: > Yes, but it seems suboptimal, incurring overhead on every rendered pixel. Why would this incur overhead? Can't the etnaviv-hardware perform swizzles for free? I'd assume you could just remap writes to gl_FragColor-compoents... > > Another way th

Re: [Mesa-dev] Question about handling RGBA/BGRA in etnaviv driver

Hi Wladimir, 2017-02-03 11:06 GMT+01:00 Wladimir : > Yes, but it seems suboptimal, incurring overhead on every rendered pixel. > > Another way that I just realized would be to convert a texture to BGRA the > first time it's rendered to. > > In contrast to the shader solution that has only a one-ti

Re: [Mesa-dev] Question about handling RGBA/BGRA in etnaviv driver

Hi Wladimir, this is about the userspace component of the driver, so dri-devel isn't the correct list for this question, you should instead CC the MESA dev list, even if mostly the same people hang out on those lists. Done that for you now. Regards, Lucas Am Freitag, den 03.02.2017, 10:56 +01

Re: [Mesa-dev] Question about handling RGBA/BGRA in etnaviv driver

Yes, but it seems suboptimal, incurring overhead on every rendered pixel. Another way that I just realized would be to convert a texture to BGRA the first time it's rendered to. In contrast to the shader solution that has only a one-time overhead. Is this a stupid idea for any reason? Wladimir

Re: [Mesa-dev] Question about tesselation shader out varyings and transform feedback

On 12/08/16 02:14, Timothy Arceri wrote: > On Thu, 2016-08-11 at 17:10 +0200, Alejandro Piñeiro wrote: >> On 05/08/16 12:20, Alejandro Piñeiro wrote: >>> On 05/08/16 01:53, Timothy Arceri wrote: On Thu, 2016-08-04 at 18:36 +0200, Alejandro Piñeiro wrote: > Hi, > > these days I have

Re: [Mesa-dev] Question about tesselation shader out varyings and transform feedback

On Thu, 2016-08-11 at 17:10 +0200, Alejandro Piñeiro wrote: > On 05/08/16 12:20, Alejandro Piñeiro wrote: > > > > On 05/08/16 01:53, Timothy Arceri wrote: > > > > > > On Thu, 2016-08-04 at 18:36 +0200, Alejandro Piñeiro wrote: > > > > > > > > Hi, > > > > > > > > these days I have been trying to

Re: [Mesa-dev] Question about tesselation shader out varyings and transform feedback

On 05/08/16 12:20, Alejandro Piñeiro wrote: > On 05/08/16 01:53, Timothy Arceri wrote: >> On Thu, 2016-08-04 at 18:36 +0200, Alejandro Piñeiro wrote: >>> Hi, >>> >>> these days I have been trying to fix a test that uses transform >>> feedback >>> on the out varying of a tessellation shader. The rel

Re: [Mesa-dev] Question about tesselation shader out varyings and transform feedback

On 05/08/16 01:53, Timothy Arceri wrote: > On Thu, 2016-08-04 at 18:36 +0200, Alejandro Piñeiro wrote: >> Hi, >> >> these days I have been trying to fix a test that uses transform >> feedback >> on the out varying of a tessellation shader. The relevant part on >> that >> shader is like this: >> >>

Re: [Mesa-dev] Question about tesselation shader out varyings and transform feedback

On Thu, 2016-08-04 at 18:36 +0200, Alejandro Piñeiro wrote: > Hi, > > these days I have been trying to fix a test that uses transform > feedback > on the out varying of a tessellation shader. The relevant part on > that > shader is like this: > >    layout (vertices=4) out; > >    out block { ve

[Mesa-dev] Question about tesselation shader out varyings and transform feedback

Hi, these days I have been trying to fix a test that uses transform feedback on the out varying of a tessellation shader. The relevant part on that shader is like this: layout (vertices=4) out; out block { vec4 value; } user_out[]; The test tries to use block.value as the varying name whe

Re: [Mesa-dev] Question about OSMesaCreateContextAttribs?

Hi Brian, On Tuesday, July 05, 2016 08:46:05 Brian Paul wrote: > Feel free to post a patch to add it to the exports list. Thanks, is on the way! Mathias ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listi

Re: [Mesa-dev] Question about OSMesaCreateContextAttribs?

On 06/30/2016 11:34 PM, Mathias Fröhlich wrote: Hi, Is OSMesaCreateContextAttribs supposed to be an extension function that should not be linked against and queried for using OSMesaGetProcAddress or is that a public api function? Either. If the application is sure to be linked against a new

[Mesa-dev] Question about OSMesaCreateContextAttribs?

Hi, Is OSMesaCreateContextAttribs supposed to be an extension function that should not be linked against and queried for using OSMesaGetProcAddress or is that a public api function? If I look into the source I could think its public since it's listed in the public header and marked as GLAPI. But

Re: [Mesa-dev] question on GL_RED and gles

On 12/01/2015 03:10 PM, Julien Isorce wrote: On 1 December 2015 at 13:08, Tapani Pälli > wrote: Which version of Mesa are you using to test this? Ilia fixed this bug: https://bugs.freedesktop.org/show_bug.cgi?id=93126 which I believe should fix this

Re: [Mesa-dev] question on GL_RED and gles

On 1 December 2015 at 13:08, Tapani Pälli wrote: > Which version of Mesa are you using to test this? Ilia fixed this bug: > > https://bugs.freedesktop.org/show_bug.cgi?id=93126 > > which I believe should fix this issue, fix is available in current master > and Mesa 11.1. > > Hi, It is me that ope

Re: [Mesa-dev] question on GL_RED and gles

Hi; On 11/25/2015 05:24 PM, Julien Isorce wrote: Hi, In EXT_texture_rg.txt it is mentioned of GL_RED_EXT on gles 2.0. In glformats.c::_mesa_es_error_check_format_and_type returns GL_INVALID_VALUE if GL_RED_EXT(as it reaches default case) so glTexImage2D(..., GL_RED_EXT, GL_UNSIGNED_BYTE, d

Re: [Mesa-dev] question on GL_RED and gles

On Wed, 25 Nov 2015 15:24:07 + Julien Isorce wrote: > Hi, > > In EXT_texture_rg.txt it is mentioned of GL_RED_EXT on gles 2.0. > > In glformats.c::_mesa_es_error_check_format_and_type returns > GL_INVALID_VALUE if GL_RED_EXT(as it reaches default case) > so glTexImage2D(..., GL_RED_EXT, G

[Mesa-dev] question on GL_RED and gles

Hi, In EXT_texture_rg.txt it is mentioned of GL_RED_EXT on gles 2.0. In glformats.c::_mesa_es_error_check_format_and_type returns GL_INVALID_VALUE if GL_RED_EXT(as it reaches default case) so glTexImage2D(..., GL_RED_EXT, GL_UNSIGNED_BYTE, data) fails. Though GL_EXTENSIONS contains GL_EXT_text

Re: [Mesa-dev] Question: st/mesa and context-shareable shaders

On Wed, Sep 30, 2015 at 3:53 PM, Roland Scheidegger wrote: > Am 30.09.2015 um 11:41 schrieb Erik Faye-Lund: >> On Mon, Sep 28, 2015 at 4:39 PM, Roland Scheidegger >> wrote: >>> >>> In short, for simplicity, only things were sharable which were really >>> required to be shared (pretty much just a

Re: [Mesa-dev] Question: st/mesa and context-shareable shaders

Am 30.09.2015 um 11:41 schrieb Erik Faye-Lund: > On Mon, Sep 28, 2015 at 4:39 PM, Roland Scheidegger > wrote: >> >> In short, for simplicity, only things were sharable which were really >> required to be shared (pretty much just actual resources - and yes that >> doesn't work too well for GL neit

Re: [Mesa-dev] Question: st/mesa and context-shareable shaders

On Mon, Sep 28, 2015 at 4:39 PM, Roland Scheidegger wrote: > > In short, for simplicity, only things were sharable which were really > required to be shared (pretty much just actual resources - and yes that > doesn't work too well for GL neither as you can't share sampler/rt > views, let's face it

Re: [Mesa-dev] Question: st/mesa and context-shareable shaders

On Mon, Sep 28, 2015 at 11:59 PM, Jose Fonseca wrote: > On 28/09/15 21:21, Marek Olšák wrote: >> >> On Mon, Sep 28, 2015 at 9:28 PM, Jose Fonseca wrote: >>> >>> On 28/09/15 14:51, Marek Olšák wrote: On Mon, Sep 28, 2015 at 2:55 PM, Jose Fonseca wrote: > > > On 27/

Re: [Mesa-dev] Question: st/mesa and context-shareable shaders

On 28/09/15 15:30, Rob Clark wrote: On Mon, Sep 28, 2015 at 8:55 AM, Jose Fonseca wrote: I see only 2 options out of this: 1) Removing the context pointer from the shader keys. If drivers need this, they should handle it by themselves. This will simplify st/mesa, because TCS, TES, GS won't

Re: [Mesa-dev] Question: st/mesa and context-shareable shaders

On 28/09/15 21:21, Marek Olšák wrote: On Mon, Sep 28, 2015 at 9:28 PM, Jose Fonseca wrote: On 28/09/15 14:51, Marek Olšák wrote: On Mon, Sep 28, 2015 at 2:55 PM, Jose Fonseca wrote: On 27/09/15 19:14, Marek Olšák wrote: Hi, For some reason, st/mesa assumes that shaders can't be shared

Re: [Mesa-dev] Question: st/mesa and context-shareable shaders

On Mon, Sep 28, 2015 at 9:28 PM, Jose Fonseca wrote: > On 28/09/15 14:51, Marek Olšák wrote: >> >> On Mon, Sep 28, 2015 at 2:55 PM, Jose Fonseca wrote: >>> >>> On 27/09/15 19:14, Marek Olšák wrote: Hi, For some reason, st/mesa assumes that shaders can't be shared by

Re: [Mesa-dev] Question: st/mesa and context-shareable shaders

On 28/09/15 14:51, Marek Olšák wrote: On Mon, Sep 28, 2015 at 2:55 PM, Jose Fonseca wrote: On 27/09/15 19:14, Marek Olšák wrote: Hi, For some reason, st/mesa assumes that shaders can't be shared by multiple contexts and therefore has a context pointer in shader keys. I'd like to get rid of t

Re: [Mesa-dev] Question: st/mesa and context-shareable shaders

Am 28.09.2015 um 15:51 schrieb Marek Olšák: > On Mon, Sep 28, 2015 at 2:55 PM, Jose Fonseca wrote: >> On 27/09/15 19:14, Marek Olšák wrote: >>> >>> Hi, >>> >>> For some reason, st/mesa assumes that shaders can't be shared by >>> multiple contexts and therefore has a context pointer in shader keys.

Re: [Mesa-dev] Question: st/mesa and context-shareable shaders

On Mon, Sep 28, 2015 at 8:55 AM, Jose Fonseca wrote: > > >> I see only 2 options out of this: >> >> 1) Removing the context pointer from the shader keys. If drivers need >> this, they should handle it by themselves. This will simplify st/mesa, >> because TCS, TES, GS won't need the variant-trackin

Re: [Mesa-dev] Question: st/mesa and context-shareable shaders

On Mon, Sep 28, 2015 at 2:55 PM, Jose Fonseca wrote: > On 27/09/15 19:14, Marek Olšák wrote: >> >> Hi, >> >> For some reason, st/mesa assumes that shaders can't be shared by >> multiple contexts and therefore has a context pointer in shader keys. >> I'd like to get rid of this dependency, because

Re: [Mesa-dev] Question: st/mesa and context-shareable shaders

On 27/09/15 19:14, Marek Olšák wrote: Hi, For some reason, st/mesa assumes that shaders can't be shared by multiple contexts and therefore has a context pointer in shader keys. I'd like to get rid of this dependency, because there is no reason why shaders would need to be tied to a context. In f

Re: [Mesa-dev] Question: st/mesa and context-shareable shaders

On Sun, Sep 27, 2015 at 10:41 PM, Ilia Mirkin wrote: > On Sun, Sep 27, 2015 at 2:25 PM, Marek Olšák wrote: >> On Sun, Sep 27, 2015 at 8:21 PM, Ilia Mirkin wrote: >>> On Sun, Sep 27, 2015 at 2:14 PM, Marek Olšák wrote: Hi, For some reason, st/mesa assumes that shaders can't be sha

Re: [Mesa-dev] Question: st/mesa and context-shareable shaders

On Sun, Sep 27, 2015 at 2:25 PM, Marek Olšák wrote: > On Sun, Sep 27, 2015 at 8:21 PM, Ilia Mirkin wrote: >> On Sun, Sep 27, 2015 at 2:14 PM, Marek Olšák wrote: >>> Hi, >>> >>> For some reason, st/mesa assumes that shaders can't be shared by >>> multiple contexts and therefore has a context poin

Re: [Mesa-dev] Question: st/mesa and context-shareable shaders

On Sun, Sep 27, 2015 at 8:21 PM, Ilia Mirkin wrote: > On Sun, Sep 27, 2015 at 2:14 PM, Marek Olšák wrote: >> Hi, >> >> For some reason, st/mesa assumes that shaders can't be shared by >> multiple contexts and therefore has a context pointer in shader keys. >> I'd like to get rid of this dependenc

Re: [Mesa-dev] Question: st/mesa and context-shareable shaders

On Sun, Sep 27, 2015 at 2:14 PM, Marek Olšák wrote: > Hi, > > For some reason, st/mesa assumes that shaders can't be shared by > multiple contexts and therefore has a context pointer in shader keys. > I'd like to get rid of this dependency, because there is no reason why > shaders would need to be

[Mesa-dev] Question: st/mesa and context-shareable shaders

Hi, For some reason, st/mesa assumes that shaders can't be shared by multiple contexts and therefore has a context pointer in shader keys. I'd like to get rid of this dependency, because there is no reason why shaders would need to be tied to a context. In fact, shaders don't even need a device, t

Re: [Mesa-dev] Question regarding dri2_egl_display conversion

> > I'm trying to find the definition of "function" dri2_egl_display but failed. > > > Hi Jaeyong, > > The function is wrapped with a help of _EGL_DRIVER_STANDARD_TYPECASTS and > _EGL_DRIVER_TYPECAST macros as defined in src/egl/main/egldriver.h > Thanks, it is exactly what I want :-) Jaeyong

Re: [Mesa-dev] Question regarding dri2_egl_display conversion

On 01/08/14 03:01, Jaeyong Yoo wrote: > Hello Mesa :-) > > I'm reading the source code and I've got a simple question. > > In egl_dri2.c, I saw the following code: > > dri2_dpy = disp->DriverData; > > > which is casting _EGLDisplay->DriverData to dri2_egl_display *. > > Also, I saw the fo

[Mesa-dev] Question regarding dri2_egl_display conversion

Title: Samsung Enterprise Portal mySingle Hello Mesa :-) I'm reading the source code and I've got a simple question.   In egl_dri2.c, I saw the following code:      dri2_dpy = disp->DriverData; which is casting _EGLDisplay->DriverData to dri2_egl_display *.   Also, I saw the following code:     

Re: [Mesa-dev] Question: glsl shader input/output for arrays of arrays

>Hi all, > >First of all sorry for the newbie question but I'm having trouble figuring out >what I need to do next for the >arrays of arrays implementation. I'm just >looking for some quick pointers in the right direction. > >I'm currently looking at what needs to be done to update >ir_set_p

[Mesa-dev] Question: glsl shader input/output for arrays of arrays

Hi all, First of all sorry for the newbie question but I'm having trouble figuring out what I need to do next for the arrays of arrays implementation. I'm just looking for some quick pointers in the right direction. I'm currently looking at what needs to be done to update ir_set_program_inout

Re: [Mesa-dev] Question on OpenCL Image Support for r600g/radeonsi

On Sun, Mar 09, 2014 at 12:28:01AM +0530, ANUJ SHARMA wrote: > Hello Sir , > I am Anuj Sharma from India. I am pursuing my M.Tech Degree at Indian > Institute of Technology, Kanpur, India. > Sir Where Can i get the more detail on what should we need to implement for > the "OpenCL Image Support".

[Mesa-dev] Question on OpenCL Image Support for r600g/radeonsi

Hello Sir , I am Anuj Sharma from India. I am pursuing my M.Tech Degree at Indian Institute of Technology, Kanpur, India. Sir Where Can i get the more detail on what should we need to implement for the "OpenCL Image Support". Thanks & regards Anuj Sharma _

Re: [Mesa-dev] Question about OSMesa

On 01/28/2014 03:49 AM, Muhammad Al-Adly wrote: Does OSMesa support OpenGL versions higher than GL1? Yes. If it does, how can I make it work? You should get a GL 2.1 context without doing anything special. -Brian ___ mesa-dev mailing list mesa-d

[Mesa-dev] Question about OSMesa

Does OSMesa support OpenGL versions higher than GL1? If it does, how can I make it work? Muhammad ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Question: in i965 question, potential bug pull vs push constants in vertex shader

Hi all, I was taking a look in i965 taking a closer look at the upload to GPU of param and pull_param for vertex shaders. What I found was this: 1) in vec4_visitor::move_uniform_array_access_to_pull_constants(), those uniforms that are relatively addressed are cloned from param to pull_para

  1   2   >