<airlied>
oh I should rebase mesa and check that later
heat has quit []
heat has joined #dri-devel
<airlied>
anholt: lower_scmp should lower that though shouldn't it?
<anholt>
would have thought
iive has quit []
ngcortes has joined #dri-devel
shsharma has joined #dri-devel
<anholt>
boo. down to a 27% perf win on this testcase after doing src_is_const not src_is_dynamically_uniform
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
shsharma has quit [Ping timeout: 480 seconds]
<anholt>
jekstrand, dschuermann: could one of you give a quick example how nir_src_is_dynamically_uniform would go wrong without lcssa? would love to get it documented.
<jekstrand>
anholt: Say you have a loop with a single non-uniform exit.
<jekstrand>
anholt: If you then have something declared inside the loop which is uniform within the context of a single loop iteration but which leaves the loop, it will show up uniform outside the loop.
<jekstrand>
However, because the loop exit was non-uniform, it might not actually be a uniform value when considered outside the loop.
<jekstrand>
LCSSA fixes this because nothing is alowed to exit the loop without going through a phi unless it came from outside the loop to begin with.
<jekstrand>
We can then analyze that phi and see that it's associated with a non-uniform loop exit and mark it accordingly.
<Lyude>
jani: i haven't had the time to look at it but i trust y'all, i'm mia right now unfortunately
ybogdano has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
<idr>
airlied, anholt: Before that commit, it would have gotten SGE instead, so... weird?
<idr>
Maybe because it's marked 'exact'?
Company has quit [Quit: Leaving]
columbarius has joined #dri-devel
<imirkin>
jenatali: sadly not a failure mode i've personally seen before
<imirkin>
(or perhaps happily?)
co1umbarius has quit [Ping timeout: 480 seconds]
<jenatali>
imirkin: Fair enough. Thanks anyway. I'll let you know when I get to the bottom of it
<jenatali>
But that might be a while
<imirkin>
jenatali: if you want to find the first failing draw, i've found retracediff (part of apitrace contrib scripts iirc) to be extremely helpful in tracking down where these issues start happening
<imirkin>
oftentimes the problem has nothing to do with the enabled feature
<jenatali>
I've gotten pretty good at debugging this kind of thing
<imirkin>
ah cool
<jenatali>
This is my third mapping layer to D3D12 lol
<imirkin>
... and i hear three times is a charm
<airlied>
idr: yeah might be the exact marking, seems like a few drivers won't be expecting slt though
<imirkin>
(unless you're joe pesci, in which case 6 times is a charm...)
<airlied>
lvp isn't the only driver setting lower_scmp
ella-0_ has joined #dri-devel
<idr>
I thought iris did too, and it's surely not expecting slt.
<airlied>
indeed it does, wierd
ella-0 has quit [Read error: Connection reset by peer]
<HdkR>
FLHerne: Do you know of a maintainer of Alpine btw? I've noticed that the SDL2 package is broken when using cmake
tursulin has quit [Read error: Connection reset by peer]
hch12907_ has quit [Ping timeout: 480 seconds]
maxzor_ has joined #dri-devel
nchery has quit [Remote host closed the connection]
nchery has joined #dri-devel
<airlied>
idr: exact shouldn't matter though, the lowering show always happen, wierd
ngcortes has quit [Remote host closed the connection]
hch12907_ has joined #dri-devel
hch12907__ has joined #dri-devel
hch12907_ has quit [Ping timeout: 480 seconds]
shsharma has joined #dri-devel
hch12907 has joined #dri-devel
maxzor_ has quit [Remote host closed the connection]
maxzor_ has joined #dri-devel
hch12907__ has quit [Ping timeout: 480 seconds]
shsharma has quit [Ping timeout: 480 seconds]
<airlied>
idr: seems like it's a bit size problem, but no idea why other drivers aren't hitting
<airlied>
jekstrand: you understand opt_algebraic don't you :)
hch12907_ has joined #dri-devel
<idr>
Lemme guess... 16-bit?
<airlied>
idr: yeah for some reason the slt expression isn't getting matched for16-bit
<idr>
That is... weird.
<idr>
Why would that only impact lp?
<airlied>
does anyone else support 16-bit?
<idr>
There's something fishy here.
<idr>
That's possible.
maxzor_ has quit [Remote host closed the connection]
maxzor_ has joined #dri-devel
<idr>
Do you have a specific test case that's failing? I can poke at it tomorrow.
<idr>
I tried that as an optimization, but, if I recall correctly, it generated identical code on Intel GPUs.
<airlied>
idr: yes that passes
dllud_ has joined #dri-devel
dllud has quit [Read error: Connection reset by peer]
<jenatali>
Out of curiosity, is there some known set of apps that handle context reset through the robustness extension?
<jenatali>
I'm wondering if it's worth my time to try to make it actually work
heat has quit [Remote host closed the connection]
<idr>
airlied: Okay... If I can't find something obvious in the morning, I'll send that patch as an MR.
<idr>
I'll take you and anholt on whatever I end up with.
mhenning has quit []
maxzor_ has quit []
lemonzest has joined #dri-devel
ramaling has quit [Server closed connection]
ramaling has joined #dri-devel
zmike has quit [Server closed connection]
zmike has joined #dri-devel
remexre has quit [Server closed connection]
remexre has joined #dri-devel
<HdkR>
How much would people fight me if I wanted to create a Metal frontend for Mesa? :D
<jenatali>
HdkR: Seems more practical than glide
shsharma has joined #dri-devel
sauce has quit [Server closed connection]
sauce has joined #dri-devel
Koniiiik has quit [Server closed connection]
Koniiiik has joined #dri-devel
cef has quit [Quit: Zoom!]
shsharma has quit [Ping timeout: 480 seconds]
ezequielg has quit [Server closed connection]
ezequielg has joined #dri-devel
cef has joined #dri-devel
<HdkR>
jenatali: I wouldn't discount how many more people would like glide than Metal. I'll discount potential future work that I do, not linkmauve's :D
javierm has quit [Server closed connection]
javierm has joined #dri-devel
shankaru has joined #dri-devel
dj-death has quit [Server closed connection]
dj-death has joined #dri-devel
zzag has quit [Server closed connection]
zzag has joined #dri-devel
eric_engestrom has quit [Server closed connection]
Prf_Jakob has quit [Server closed connection]
eric_engestrom has joined #dri-devel
Prf_Jakob has joined #dri-devel
<jenatali>
Sorry, didn't mean for that to sound critical, I think both are great. Just seems like Metal would maybe light up even more apps
<airlied>
HdkR: is this to run apple store games?
unidan has quit [Server closed connection]
<airlied>
HdkR: I assume it would be Metal on Vulkan
unidan has joined #dri-devel
<airlied>
HdkR: also you have to call KVnetlom
lemonzest has quit [charon.oftc.net kinetic.oftc.net]
lemonzest has joined #dri-devel
jessica_24 has quit [Server closed connection]
jessica_24 has joined #dri-devel
LaughingMan[m] has quit [Server closed connection]
LaughingMan[m] has joined #dri-devel
<HdkR>
airlied: Nah, I don't care about apple store games. Just think the API is nice and I would love using it on Linux with the metal-hpp bindings
<airlied>
HdkR: you could go nuts and write metal drivers for each gpu, but metal on vulkan would like provide more success
<HdkR>
As far as I'm aware the API has some features that Vulkan can't directly translate
_alice has quit [Server closed connection]
<HdkR>
Like bindless pointers
_alice has joined #dri-devel
<HdkR>
So if it was wired in to Gallium it would have the highest likelyhood of not breaking horribly :D
xerpi[m] has quit [Server closed connection]
xerpi[m] has joined #dri-devel
ifreund has quit [Server closed connection]
ifreund has joined #dri-devel
join_subline has quit [Ping timeout: 480 seconds]
<DrNick>
Direct3D had some features that Vulkan can't directly translate
<DrNick>
Like geometry shaders
shankaru has quit [Ping timeout: 480 seconds]
<airlied>
HdkR: I think metal would be too lowlevel for gallium, so a vulkan + exts model might be better
<HdkR>
hmmmm
* airlied
assumes metal is cmd buffer not ctx based
<HdkR>
But then the problem would be that I'm terrible at Vulkan
<HdkR>
and that's a major hurdle to overcome :D
Eighth_Doctor has quit [Server closed connection]
Eighth_Doctor has joined #dri-devel
yogesh_mohan has quit [Ping timeout: 480 seconds]
HayashiEsme[m] has quit [Server closed connection]
HayashiEsme[m] has joined #dri-devel
Duke`` has joined #dri-devel
arnd has quit [Server closed connection]
arnd has joined #dri-devel
shankaru has joined #dri-devel
yogesh_mohan has joined #dri-devel
idr has quit [Quit: Leaving]
<imirkin>
jenatali: chrome might? not sure.
<imirkin>
(re caring about context resets)
Duke`` has quit []
<HdkR>
Oh hey, I finally found out why I was getting chrome hangs. Apparently I enabled their Vulkan renderer
<HdkR>
Oops
Duke`` has joined #dri-devel
join_subline has joined #dri-devel
<jekstrand>
HdkR: RE: Metal. I wouldn't stop you but I also don't see much point.
<HdkR>
Pointless things, I specialize in those
tango_ is now known as Guest37
tango_ has joined #dri-devel
<airlied>
just do a metal on gallium on llvmpipe layer for extra pointlessness
<Sachiel>
leadpipe
mattrope has quit [Read error: Connection reset by peer]
<jekstrand>
If you did it on gallium then you could use alyssa's M1 work to replace Apple's native Metal. (-:
<airlied>
yeah it would be horrible on gallium, so would be only be useful in an llvmpipe only way
itoral has joined #dri-devel
<airlied>
HdkR: is there any sort of metal test suite?
Guest37 has quit [Ping timeout: 480 seconds]
sven has quit [Server closed connection]
sven has joined #dri-devel
danvet has joined #dri-devel
sdutt has quit [Read error: Connection reset by peer]
ppascher has quit [Quit: Gateway shutdown]
<HdkR>
airlied: Doubt, and I bet they would be all written in obj-c++2.0 or w/e the original language was
shsharma has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
tzimmermann has joined #dri-devel
ppascher has joined #dri-devel
shsharma has quit [Ping timeout: 480 seconds]
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
mszyprow has joined #dri-devel
mlankhorst has joined #dri-devel
mbrost_ has joined #dri-devel
<dschuermann>
anholt, jekstrand: I just looked up the nir_src_is_dynamically_uniform function. it should be renamed to *_is_statically_uniform. no dynamic involved, and thus, should be fine without lcssa.
kts has quit [Quit: Konversation terminated!]
mbrost has quit [Ping timeout: 480 seconds]
mvlad has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
shsharma has joined #dri-devel
go4godvin has quit [Server closed connection]
go4godvin has joined #dri-devel
go4godvin is now known as Guest41
mbrost_ has quit []
mbrost has joined #dri-devel
mbrost has quit []
ahajda has joined #dri-devel
shsharma has quit [Ping timeout: 480 seconds]
dviola has left #dri-devel [WeeChat 3.4]
dviola has joined #dri-devel
Venemo has quit [Server closed connection]
Venemo has joined #dri-devel
mbrost has joined #dri-devel
curro has quit [Read error: Connection reset by peer]
whald has joined #dri-devel
whald_ has joined #dri-devel
whald has quit []
whald_ has quit [Remote host closed the connection]
whald has joined #dri-devel
mbrost has quit []
rgallaispou has joined #dri-devel
<whald>
hi! when doing a gbm_bo_map with GBM_BO_TRANSFER_WRITE, is it expected to see _isl_memcpy_tiled_to_linear_sse41 in the stack trace, burning quite a lot of CPU time? i intend to write to the mapped region only and was only expecting to see the _isl_memcpy_linear_to_tiled happening in gbm_bo_unmap. (this is on Intel iris)
<whald>
so basically I was expecting GBM_BO_TRANSFER_READ -> expensive map, cheap unmap -- GBM_BO_TRANSFER_WRITE -> cheap map, expensive unmap -- GBM_BO_TRANSFER_READ_WRITE -> expensive map & unmap
<Kayden>
I believe that's expected
<Kayden>
I don't know about gbm map semantics specifically, but...that maps through the various layers to iris_transfer_map()
<Kayden>
the thing is, just because you map something for writing, doesn't mean that you guarantee you're going to overwrite the entire region you mapped
<Kayden>
so we have to read the existing data into the temporary area, let you write there, then write it back to the original
<Kayden>
usually there's a flag like PIPE_MAP_DISCARD_RANGE or GL_MAP_INVALIDATE_RANGE_BIT which says "by the way, you can throw out the exsiting contents"
<Kayden>
but I don't see any such flag in the gbm api
<MrCooper>
Kayden: GBM_BO_TRANSFER_WRITE would be pointless if so (could be dropped in favour of GBM_BO_TRANSFER_READ_WRITE)
<whald>
Kayden, I had an discussion here about the exact topic, but for amdgpu, and there the conclusion was the when mapping a region for write means I *have to* write the whole region. I was getting rendering artifacts when I did not.
<Kayden>
that's fair, maybe that's the semantics gbm should be following
<whald>
MrCooper, indeed I do not understand what's the point of these flags the way it's implemented on intel
<Kayden>
it's not really an intel thing though
<Kayden>
dri2_map_image turns these into generic gallium maps and passes no such flags
<Kayden>
so IMO that's a gallium dri2 frontend bug
<Kayden>
the other APIs that translate to those same gallium hooks allow partial writes
<pq>
forwarding patches is also fine if you know you are allowed to forward them, patch author can be different from patch submitter.
pH5 has quit [Server closed connection]
pH5 has joined #dri-devel
<javierm>
whald: you can commit with their authorship with the git-commit --author option
<whald>
javierm, pq, ok, I'll open a PR then. hope my git foo is strong enough not to mess this up ;)
<whald>
ehm, not so fast, using "Kayden from IRC" is not what I should use for the author, I guess?
<pq>
indeed
<emersion>
you can grab the info from the git log
<pq>
in irc you can check /whois kayden to see if they set their real name. If they are regulars in the project, you can probably find them in the git history by that so see what they as Author.
<whald>
oh, thanks, then I'll open the PR. thanks again!
Guest48 has quit []
<pq>
personally I would confirm with the person with if it's ok for me to forward the patch, unless you're sure it's ok
<emersion>
probably fine to open the MR and ask for an ACK in the description
<whald>
huh, then I guess I'll skip the PR part for now.
<linkmauve>
HdkR, I’ve actually got feedback that people want to use this driver once it is usable, which I didn’t expect!
<whald>
something else: is there some API I could use to do the work done (swizzeling?) in gbm_bo_unmap myself? I'd like to implement a few formats I care about and fall back to the GBM approach for stuff I have not implemented
<pq>
whald, why do you think that is a good idea?
kts_ has joined #dri-devel
<HdkR>
linkmauve: Build it and they will come!
<pq>
whald, gbm_bo_map could use the GPU to do the conversion during the copy without bothering CPU that much, and direct CPU access to the original buffer could be slower than having the GPU copy it.
kts_ has quit []
<pq>
whald, I would guess the reason intel uses the CPU directly is that the CPU access to the original buffer is fast, since it's "just" sysram. Dedicated VRAM (discrete cards) is likely a very different story.
<whald>
pq, because the memmove to the scratch buffer is taking almost as much time as what's happening in gbm_bo_unmap. i imagine to cut that time in half when skipping yet another scratch buffer.
mclasen has quit [Read error: No route to host]
mclasen has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
kts has joined #dri-devel
<whald>
pq, indeed on intel, with GBM_BO_USE_LINEAR, map + unmap are basically free. with GBM_BO_USE_RENDERING, unmapping takes quite some time.
<pq>
whald, I'm not sure I undertand, but if you intend to never run on any other machine, then sure. ;-)
<whald>
pq, OTOH, on Intel the actual rendering (on GPU) takes a hit when using linear FBs. I'd like to have fast BO updates and fast rendering.
<whald>
pq, I'd like to have it run wherever possible but we have a limited set of hardware we actually ship and if I can get some more performance out of those that's probably worth the effort.
<pq>
whald, and the developers of GBM didn't care? ;-)
<pq>
if you find something sub-optimal, why not try to fix it upstream to benefit everyone? Or is it the very API design that is holding you back?
<whald>
pq, I assume they did care, but I assume taking the burden of supporting different FB layouts off the user is part of the purpose of GBM, so there's the scratch buffer in place (at least for Intel + GBM_BO_USE_RENDERING), which i'd like to skip. :)
<whald>
pq, we absolutely submit upstream whatever we come up with, but here I indeed the API does not support what I intend to do. or I'm missing something. that's why I ask. :)
<pq>
so instead you would use the scratch buffer in tiled format?
<whald>
pq, I think I would want to have no scratch buffer at all to save the memory bandwidth.
<pq>
but then what about discrete cards?
<pq>
the kernel UAPI for mmapping buffers directly exists, btw. so you can try to get a raw map if you want.
<pq>
but for a program that is supposed to run on more than one model or vendor of GPU that can easily backfire
<whald>
pq, so when I known I can "do it", I could mmap the BO FD and write swizzled data there?
<pq>
I believe so - obviously I've never tried for non-linear buffers
<whald>
pq, wouldn't this just mean to check the BO modifiers, decide I have implemented my "fast path" for those and otherwise go the bo map/unmap route?
<pq>
yup, assuming the mmap does not have driver-specific behavior
<whald>
pq, then I guess there's only one way to find out! ;-) thanks for the input!
<pq>
ISTR some hardware having blocks that can give the illusion of a linear mmap, but these blocks are scarce.
<pq>
you also have the problem that a direct CPU mmap can be slower to access than a copy in both directions, but when that happens I can't really say
<whald>
pq, I played around with this some time ago and noticed that GPU -> CPU transfers on amdgpu are very slow, the other way around it's fast. on Intel both are fast. but I care about writing only, so maybe I'm lucky.
<pq>
if you work like a game, you're on the sweet path, I guess :-)
shankaru has quit [Quit: Leaving.]
pcercuei has joined #dri-devel
shankaru has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.4]
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
lemonzest has joined #dri-devel
nchery is now known as Guest55
nchery has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
Guest55 has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
rasterman has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
devilhorns has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
flacks has quit [Quit: Quitter]
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
flacks has joined #dri-devel
itoral has quit [Remote host closed the connection]
<javierm>
tzimmermann: Andy suggesting me to use a macro that haven't even landed in mainline yet is a next level of bikeshedding that never experienced before :)
<tzimmermann>
:)
<tzimmermann>
i think the format helpers are fine
<javierm>
yeah, agreed
<tzimmermann>
we can optimize performance later, if necessary
<javierm>
tzimmermann: as mentioned in the ML I think that's important to think about readbility and robustness, maybe even more than performance
<javierm>
I spent a non-trivial amount of time wrapping my head around the format helpers
<tzimmermann>
:)
<javierm>
tzimmermann: do you have any more concerns about the driver?
<javierm>
tzimmermann: I think that will just go ahead and address the last comments from Andy to post a v5 later today, but will wait if you plan to take a look
<tzimmermann>
let me check quickly...
<javierm>
tzimmermann: thanks!
<tzimmermann>
javierm, there was one thing in patch 3
<tzimmermann>
javierm, and one in patch 2
<javierm>
tzimmermann: gotcha. Just read your comments, thanks
<tzimmermann>
yw
<tango_>
feel free to redirect me to the best place where to report this. I'm using the amdgpu driver and since at least kernel 5.15.something every time anything tries to access /dev/kfd I get a dmesg spam to the tune of:
<tzimmermann>
javierm, not quiet. it could still happen that you enable the pipe with a virtual screen and have to adjust the view accordingly. best copy the rsp code from simpledrm's pipe_enable
<tzimmermann>
javierm, but do we really clip here? hmmm....
<javierm>
tzimmermann: I use drm_rect_intersect() in the pipe update callback but maybe that's not needed as well ?
<javierm>
I use the shadow buffers bigger than display virtual screen support so I guess for update is correct to use that ?
<tzimmermann>
javierm, i just checked your driver and that example link. what you do should be correct.
<javierm>
tzimmermann: cool, thanks for the confirmation
<tzimmermann>
sorry it's friday afternoon here...
<javierm>
tzimmermann: no worries. I'm reaching my level of understanding about DRM buffers handling so I preferred to confirm before sending a wrong v5 :)
<javierm>
tzimmermann: thanks a lot for all your feedback and patience for the explanations
<tzimmermann>
but i wonder if simpledrm gets it right. that has to wait until monday
<bbrezillon>
does anyone know if it's allowed to load a texel from a VK_DESCRIPTOR_TYPE_SAMPLED_IMAGE descriptor (access the sampled-image without its sampler)?
<bbrezillon>
oh, forgot to add the 'on a cube image view' constraint
itoral has joined #dri-devel
<bbrezillon>
the reason I'm asking is that d3d12 doesn't allow loading a texel from a cube texture (textureLoad() doesn't work on cube SRVs), and if we need to support that case, that implies adding SRVs resources exposing cubes as 2darrays
kts has joined #dri-devel
<bbrezillon>
we do that cube -> 2d-array lowering for storage images, but that one is easier, because we know the resource will never be sampled from, so we can drop the cube image and replace it by a 2Darray. But if sampled-images need to support both txf and tex, we need to duplicate the resource and pick one or the other depending on the texture instruction
<bbrezillon>
jekstrand: ^
<jekstrand>
bbrezillon: Vulkan has no such restriction.
<bbrezillon>
that's what I thought. Oh well, I'll add those cube-as-2array descs then
Company has quit [Quit: Leaving]
Company has joined #dri-devel
<jenatali>
:(
ccr has quit [Server closed connection]
ccr has joined #dri-devel
<agd5f>
MrCooper, daniels: either give me maintainer privileges or add shashank as a developer for xf86-video-amdgpu?
<agd5f>
*can you
<MrCooper>
sure, sec
Terman has quit [Server closed connection]
Terman has joined #dri-devel
<daniels>
agd5f: you've got the keys to the kingdom
<mssx86>
greetings, i'm on a i965 igpu (i5-3320m), building 22.0.0-rc2 tells me that classic i965 is deprecated. in that case should i go with i915 or crocus for the gallium driver?
<ajax>
crocus
<mssx86>
thank you for your response, i have xorg-server built with dri enabled, do i need to rebuild x's server after switching to gallium?
<ajax>
nope
<kisak>
i915g is intel gen 3, crocus is gen 4-7.5 (and a little of gen 8)
<mssx86>
ajax: thanks a bunch, i appreciate it.
robink has joined #dri-devel
<kisak>
^ in the context of mesa drivers, it's all i915 on the kernel side
<mssx86>
kisak: my build for i915 just finished, was planning on doing crocus, should i not if crocus is for haswell and above?
<kisak>
Haswell is intel gen 7.5
<mssx86>
oh right.
<mssx86>
going with crocus then.
<mssx86>
will report back, i genuinely appreciate your responses, thnak you.
mssx86 has quit [Quit: leaving]
<FLHerne>
kisak: Intel (used to) brand processors as 'i7 gen 3' or whatever
<kisak>
FLHerne: I'm aware of the difference between the cpu die generation and the gpu-sided generation
<FLHerne>
where I think gen 1 was Nehalem, so Haswell would be 4 IIRC
<FLHerne>
ok, but mssx86 wasn't :p
<kisak>
fair enough
<alyssa>
oops I think I accidentally became a kernel dev
<HdkR>
oops
<alyssa>
hate when that happens
<alyssa>
sneaks up on you
Guest79 has quit []
<jannau>
more than an unnamed drm driver for cursed HW would proof?
bnieuwenhuizen has joined #dri-devel
<airlied>
alyssa: next is accidentally becoming a kernel maintainer
<alyssa>
airlied: oh no
<alyssa>
jannau: i'm pretty sure i named that driver "panfrost" ;)
gouchi has quit [Remote host closed the connection]
gouchi has joined #dri-devel
mvlad has quit [Remote host closed the connection]
lemonzest has quit [Read error: Connection reset by peer]
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
lcn has quit [Server closed connection]
lcn has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
<gawin>
someone knows cause of "InternalError (Unable to get sensible measurements for estimation at es2pShaderOperatorTests.cpp:718)" in piglit? (happens on vertex shaders a lot)
<linkmauve>
alyssa, that happened to me the last time I bought a phone, and then I became a maintainer too.
<linkmauve>
So weird how things just happen.
<alyssa>
linkmauve: truly
angerctl has quit [Server closed connection]
angerctl has joined #dri-devel
gouchi has quit [Quit: Quitte]
italove31 has quit [Server closed connection]
italove31 has joined #dri-devel
ahajda has joined #dri-devel
<alyssa>
ok.. time to figure out how to make the panfrost blitter better
Akari has quit [Server closed connection]
Akari has joined #dri-devel
LexSfX has quit []
haagch has quit [Server closed connection]
haagch has joined #dri-devel
nsneck_ has quit [Server closed connection]
curro has joined #dri-devel
nsneck_ has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
<alyssa>
jekstrand: if I need to solve a 3x3 linear system in a blitter [on the CPU, O(1) per blit] have i taken a wrong turn
gawin has quit [Remote host closed the connection]
<alyssa>
(If blitting with dst x,y != 0, need to compute varyings that interpolate to what we want.]
APic has quit [Server closed connection]
APic has joined #dri-devel
<imirkin>
alyssa: can you disable viewport transforms?
<alyssa>
not meaningfully
<imirkin>
alyssa: on nouveau, we do blits by disabling viewport transforms, so the coords are all the natural coords
<alyssa>
i'm trying to implement blits with a special "full screen draw" primitives
<alyssa>
Oh, the viewport transform is always disabled
<imirkin>
ah i see
<imirkin>
and no scissors i assume? :)
<alyssa>
scissor doesn't help
<imirkin>
and/or "window rectangle"
<alyssa>
the issue is varying interpolation
* imirkin
tries to remember how this is handled in nouveau
<alyssa>
(Logically interpolating from (dst x, dst y), the hardware actually interpolates from (0,0) )
<imirkin>
right
<alyssa>
if blitting to a linear image, could play games with the pointers to make that physically 0,0
<alyssa>
doesn't usually work for tiled and especially not compressed
<alyssa>
then again i think for compressed images we have.. bigger.. problems..